These are the slides from the talk I gave at GDC 2026: HOW WE DRAW A 3D SPRITE WORLD: The Stylized Art of Never’s End.
They’ll be a bit hard to follow without the video, but that should show up online eventually. Until then, everyone that saw the talk in person can use them as reference.
PowerPoint (pptx) / 341 MB / has all the video and animations
PDF / 7 MB / only still images
While working on some new graphics features, I needed to store and load an intermediate image files with floating point pixel data. Up until this point any intermediate texture data generated by my build pipeline was stored as TGA files. This was useful if I needed to inspect the data because I could just load it up into Photoshop and see what was what.
However, it also meant I was limited to a very small set of pixel data formats. I needed a new solution so I started looking at image file formats that could handle floating point data. Immediately I encountered formats built for HDR images like RGBE and OpenEXR, but was not pleased.
This post will be a bit different than my normal technical posts. Rather than covering a successful finished system, this will be a glimpse into the process of (hopefully) getting to that point in the future.
With INVERSUS finally out on all platforms, I can clean up some of the engine’s rough edges, and one of the bigger pain points has been the font pipeline. When it comes to refactoring workflows and engine architecture, I think it’s important to find tractable small steps you can take on the path towards your desired goal. I have a fuzzy picture of how I’d like things to be, and I make small improvements while at the same time getting a better focus on the destination.
In my experience, the complexity of properly rendering text is an underappreciated problem by engineers that have never worked on it. It seems so simple! There are really only three steps:
So which of those steps is the hard one? Unfortunately, if you want to render crisp text in multiple languages across the world, all of them are the hard one.
When discussing the visual style of INVERSUS, there has always been an amusing contrast between the random YouTube comment saying that “this could run on an Atari” and the periodic questions asking how I’m actually managing to draw what is happening on screen. We’re going to take a detailed walk through how INVERSUS Deluxe composes a frame, but for fun let’s start off by looking at an actual demake of INVERSUS for Atari that Ed Fries was toying around with (believe it or not, just finding a way to render the obstructions on the map was non-trivial).
Can you spot the difference?