Another DEX compile, this time a port of the latest Lua API showing off some other aspects of the compiler.
If you haven't heard of DEX yet, you can go read my other blog post here on how I built a C++ to C# compiler.

The main goal here was to reduce the module size to the point where a DEX module could be shared around as if it was a normal C# library, uploaded to sbox.game, etc. Essentially that means we need to uglify the compiled DEX code even further, getting rid of newlines and other pretty printing stuff, and consolidating variable names so that they take as few characters as possible. That includes function names too, everything that isn't publicly exposed.

There aren't any fantastic C# minifiers out there, because there hasn't really been a need for them yet. The only actively maintained minifier doesn't rename anything, it just kills whitespace, so I had to modify DExTr to support minification out of the box.
 
Lucky for me, it's really easy to determine how many times a value is used in LLVM, so we can be pretty smart about how variable names are chosen (assigning the shortest minified names to the most-used variables and functions).

The initial embedded memory is also compressed as a base64 string in order to squeeze as much as we can in.

But anyway, with minification enabled now the module is just one massive line of code, and it halved the module size from 8MB down to 4MB. When compressed it's just over 800KB.
There's still some dead whitespace here and there but I'll be tightening that up over time.

The other neat thing I'm doing here which is different from my previous DEX stuff is that I've hidden away the ugly, gory details of the module (memory, const char*, etc) behind a nice clean C# interface. That way dealing with pointers is the library's problem, and the game only has to worry about dealing with Lua.

I've also added some basic support to allow you to push your own C# lambdas and functions into the module as C function pointers, which allowed me to dynamically set up the Lua VM with s&box API bindings at runtime through the type library.

That way everything's just hooked up for you automatically and you can use the s&box API the exact same way you would in C#, except it's all completely runtime.
The API's not fully comprehensive yet, notably there still isn't support for arrays or any complex C# stuff like generics etc., but it's enough to fiddle about with and it shows off what's possible.

These bindings are all handwritten at this point, though in the future it's definitely going to make sense to start working on some automatic binding tools. I believe the Emscripten equivalent of this is called embind.

No fucking clue.
I've gotten games, emulators, and full-on languages running almost flawlessly.
Seems like the sky is kind of the limit here.

I thought about porting over some JavaScript engines or maybe even doing some stupid C#-in-C# shit but that doesn't massively interest me at this point. Laylad suggested the other day that getting the GMod Lua API up and running might be a cool project.

But glua's a little too heavily integrated with the Source engine. I might be able to make basic addons work with simple API shims but I'm more of an all-or-nothing kinda guy. If the project wouldn't support Lightsaber SWEPs or drivable Deloreans out of the box I don't really give a fuck.

Oh yeah, I've still got that SourceBox code lying around...