What does it take to bring these things that were originally designed for completely different OS platforms and instruction sets into PPC OS X, if you don't mind my asking?
Having a working and modern development environment is a huge part of what makes this possible. Barracuda's PPCPorts project and Iain Sandoe's work on gcc14 + darwin-xtools were pretty much required to do any of this.
When I'm not stuck on a 20 year old compiler and having to cut out or rewrite entire parts of a codebase, the amount of work involved shrinks quite a bit. There are still a number of challenges:
- Endianness: this is a problem that scales with the size and complexity of the codebase. If you take a 32 bit hex value like `0x12345678`, big endian will store that value in memory as `12 34 56 78`. Little endian stores it as `78 56 34 12`. This makes huge sections of code instantly suspect - you now need to comb through every single case where integers, files, network protocols and raw memory are being handled and ensure that byte order is being fed correctly. In a small game engine, this may be 2-10 different patches, like changing a texture loading function to byteswap a little-endian texture file at runtime. In a large game engine (like Source) this is often tens or hundreds of small patches, combined with lots of debugging, instrumentation, and watching for very subtle behavior issues.
- OpenGL 2.1-ish: Leopard's GPU drivers are very quirky and OpenGL 2.1 support is more like "best effort". I don't even want to think about Tiger. While glsl120 shaders will compile and are technically supported, they do not behave appropriately at all and the driver doesn't give you a true 2.1 context. I have personally encountered very strange behavior with FBO texture mipmapping, multithreaded contexts, framebuffer blitting, context creation, multisample antialiasing, NPOT textures, and render target presentation. This is the most annoying set of issues I have dealt with in Source/OpenMW. With enough work it's definitely possible to get an OpenGL3/4 renderer working in an OpenGL 2.0 context, but this is usually a slippery slope of alternative rendering paths that kill performance or sacrifice visual quality. Anything without OpenGL support, you're pretty much SOL or writing it yourself. We have no Vulkan and no DirectX.
- OS-specific: Leopard is pretty good about POSIX compliance, but there are still missing OS features and APIs that you'll need to work around - clock_gettime() is weird, threading can misbehave, you're still technically on a 32-bit OS so virtual memory ceilings are very real.. you're also missing a lot of modern conveniences (No built-in JSON support, outdated TLS/SSL)
- Hardware/time: Keeping my Quad in working order is a huge prerequisite! I don't have a working cross compilation environment yet (although I'd like to soon), and so a huge chunk of my work is "hurry up and wait for the compiler", lol.
- SIMD/PPC specific: Not really as many issues here as you'd think, just depends on the codebase. This is a real blocker for things like JIT recompilers or other SIMD heavy code (think emulators, web browsers) However, you'd be surprised how much stuff just compiles and works once you account for endianness and OS level jank.
There are a handful of edge cases with iains' darwin-xtools that cause crashes when linking or bad optimizations that can cause crashes, and I'd like to see those fixed, but for a completely volunteer effort it is damn impressive and I am so thankful that there are smart people out there who have put in some real work to even allow me to work on stuff like this.
All of this work is just for fun and challenge, and hopefully to give someone a reason to hang on to that old Mac. I try to keep my GitHub updated with patches as I make them and I hope people can find my code helpful and informative. There was a lot of trial-and-error along the way, so hopefully I can save someone else from making the same mistakes I did.
🙂
