The approach is somewhat interesting: They model the different platforms the code will run on as classes and set them up to inherit from one another, which drives the optimization possibilities, register allocations and the code generation. Because of the inheritance, they claim that porting to neighboring CPU families is easy since they don't have to duplicate the code for the instruction set mappings, etc. and only specialize the certain parts that are different.
This is a really clean approach. I've been doing something similar for my CL game engine, but I hit a few gotchas worth mentioning:
The Wine overhead for the REPL is surprisingly minimal - maybe 50-100MB extra RAM and no noticeable latency. The real pain point is when you need Windows-specific debugging. Wine's implementation of Windows debugging APIs is... spotty. If you hit a nasty FFI crash, you're basically flying blind compared to native development.
For the DLL loading, one trick I learned: use GetProcAddress equivalents through CFFI instead of relying on load-time symbol resolution. This lets you gracefully handle missing functions between different Windows versions without crashing on startup. Particularly useful if you're targeting both Windows 7 holdouts and Windows 11.
Also worth noting: if you're distributing commercially, the mingw runtime has some licensing quirks. The "posix" threading model links against winpthread which is GPL (with exceptions), while the "win32" model avoids this but lacks some C++11 features. For pure C code it's usually fine, but check your dependencies.
The 40MB executable size is brutal though. I ended up using UPX on the Windows builds which gets it down to ~12MB with decent decompression speed. Just add upx --best aero-fighter.exe to your build script. Some antivirus software gets twitchy about UPX-compressed executables, but it's generally fine for games.
Anyone know if SBCL's Windows fork has plans to add core compression? Seems like low-hanging fruit given how well it works on other platforms.
Thanks for this! I'll look into compressing the `.exe` down.
With regards to licensing, I think I'm okay. Raylib itself is permissive, and I own the rest of the dependencies (save two - one is MIT and the other is public domain).
I'm going to be that guy and say "this isn't cross-compiling." I was thinking "Why not just use Wine" when I clicked on the link, and that's what they are doing.
Lucid Common Lisp used to have cross-compilation features built-in: https://www.dreamsongs.com/Files/cp.pdf
The approach is somewhat interesting: They model the different platforms the code will run on as classes and set them up to inherit from one another, which drives the optimization possibilities, register allocations and the code generation. Because of the inheritance, they claim that porting to neighboring CPU families is easy since they don't have to duplicate the code for the instruction set mappings, etc. and only specialize the certain parts that are different.
Here's a response:
This is a really clean approach. I've been doing something similar for my CL game engine, but I hit a few gotchas worth mentioning:
The Wine overhead for the REPL is surprisingly minimal - maybe 50-100MB extra RAM and no noticeable latency. The real pain point is when you need Windows-specific debugging. Wine's implementation of Windows debugging APIs is... spotty. If you hit a nasty FFI crash, you're basically flying blind compared to native development.
For the DLL loading, one trick I learned: use GetProcAddress equivalents through CFFI instead of relying on load-time symbol resolution. This lets you gracefully handle missing functions between different Windows versions without crashing on startup. Particularly useful if you're targeting both Windows 7 holdouts and Windows 11.
Also worth noting: if you're distributing commercially, the mingw runtime has some licensing quirks. The "posix" threading model links against winpthread which is GPL (with exceptions), while the "win32" model avoids this but lacks some C++11 features. For pure C code it's usually fine, but check your dependencies.
The 40MB executable size is brutal though. I ended up using UPX on the Windows builds which gets it down to ~12MB with decent decompression speed. Just add upx --best aero-fighter.exe to your build script. Some antivirus software gets twitchy about UPX-compressed executables, but it's generally fine for games.
Anyone know if SBCL's Windows fork has plans to add core compression? Seems like low-hanging fruit given how well it works on other platforms.
Thanks for this! I'll look into compressing the `.exe` down.
With regards to licensing, I think I'm okay. Raylib itself is permissive, and I own the rest of the dependencies (save two - one is MIT and the other is public domain).
You're responding to an AI post.
Wouldn't Cosomoplitan be the true cross-compiling in this case?
https://github.com/jart/cosmopolitan
no GUI lib for cosmopolitan libc yet, afaik.
Nit: the Aero Fighter link points to the raylib repository instead of the aero fighter repo
Fixed, thank you.
I'm going to be that guy and say "this isn't cross-compiling." I was thinking "Why not just use Wine" when I clicked on the link, and that's what they are doing.