A behind the scenes look

A lot of work goes in to making a 3D game from scratch in C++98 using tools and hardware from the 90's. Exactly all of the things you take for granted when making a game using an off-the-shelf game engine like Godot, Unity or Unreal engine has to be implemented by hand. This is even more true when targeting the low-level rendering API QuickDraw3D RAVE, the API that predated OpenGL as the fastest 3D hardware acceleration API on Macintosh. In OpenGL or DirectX you can basically just follow some tutorial, draw triangles and see them on the screen in an hour or so, but with RAVE there is no such thing as a tutorial, the documentation was never even finished and was difficult to find. It has taken a lot of experimentation to get something to show up on the screen without freezing the computer (yes, this happens very easily with RAVE). For example, RAVE does not support clipping, so before rendering you need to clip the parts of a triangle that intersects the edges of the screen. You might think: "What does it matter if a triangle is drawn outside the screen?", to which I'll respond that as it turns out it matters a whole lot. If you try to draw something that intersects the top edge of the screen or window, the Macintosh will catastrophically freeze and you can even have your hard drive corrupted. I've had to reboot the mac hundreds or even thousands of times at this point, and the hard drive has been corrupted at least once by this issue. Even if it doesn't freeze in some cases, you can still get triangle soup glitches with inverted and infinitely stretched triangles. I figured out many of these quirks and limitations of RAVE when making Blokz RAVE, but I'm still learning new things.

Early screenshot of the first time I got clipping to work. The red triangle is from a small code sample I found on a CD from the mid-90's.

Rendering triangles fast may sound difficult (it is), but to me it is the easy part and I struggle much more with physics and game logic. What I'm currently working on is figuring out what level of dynamic collision simulation the game needs to feel fun and fair, how much the hardware can let me do per frame, what acceleration structures I can use for this game, and what tradeoffs I need to do. The bar I've set for myself for this game is much higher than my previous game Blokz RAVE, which naturally means that the scope of the game has increased exponentially, and the time it will take to reach a fun and playable demo is longer. I do make a lot of progress, almost every day, and I will reach the goal.

Some of the things I have worked on the past few days:

• Debug rendering improvements, to make it easier to quickly draw up a visualization of some complex 3D math
• Intersection tests for planes, frustums, oriented bounding boxes
• Rendering API improvements. Notably a fix for an issue where the API would only let me draw transparent items such as the stars in the foreground, which meant that the stars and the sun would be drawn on top of the rings and space ship.
• Better rendering of speed lines (previously drawn as just white points). This draws inspiration from I-War 2.

Screenshot of debug rendering of Oriented Bounding Boxes (OBBs)

Screenshot of debug rendering of vertex normals and clipped triangles. If I fly any closer, the computer freezes (the bug still exists in this part of the code!)

Stay tuned for more updates if you are interested in reading technical rants like this!