Batch Rendering, Light Sprite Fix

Hey Folks! I managed to make a pretty big optimization today to the renderer, as well as fix a few visual issues with the headlamp.

The headlamp was just finishing-up yesterday's work. I found and fixed the scaling and position issues for the sprite, and also hooked-up the sprite to the on/off code triggered when the helmet is donned/removed. Now, we get a nice little pin light appearing from where the helmet's light source emits, and it follows the crew around correctly as they animate.

Moving on, I decided to tackle that material batching issue I spoke of before. After a bit more research, I realized I was basically making new instances of multiple materials each time an item was added to the scene. And if you can imagine a ship with over a thousand parts, many of which are just the same sprite over and over (e.g. walls and floors), that's a lot of wasted copying. What's more, each of those wall/floor copies has to be loaded from the CPU to be drawn on the GPU individually, which is a tremendous waste of processing time.

Now that I have a better handle on how this works, I was able to get these repeated items to share the same material instance. What this means is that the game only has to load one such item from the CPU to GPU, and then copy it to the screen at a different place for each tile. I.e. a "batch" of renders.

What this means in practice, is that the simple character generation station you see in today's screenshot requires 273 draw calls. If you look closely at the "Statistics" debug inset, you'll also notice it says "Saved by batching: 873." In other words, we reduced the number of draw calls per-frame from 1046 to 273.

Even more impressive is when I loaded the big ship layout I've been using for stress-testing. This ship is several times as big, with multiple thousands of sprites compared to a mere thousand. And the draw calls required there? Also 270ish. And the framerate was a healthy 60+!

There's still more that could be done. Some other places are making the same material instancing mistakes. But they're used a lot less, so the impact isn't as big. They'll need addressing eventually, but I might move on before doing them all. Plus, a good chunk of them are inevitable, as they represent individual UI items like buttons, button labels, floating text, list items in the UI, etc.

It's a nearly invisible change in a screenshot, but it should hopefully make a big difference in framerate and memory leaking. A net improvement over the old renderer!

Tags: Ostranauts