Just about 10 days in and Turnover’s KS campaign is nearly 20% funded. So far, so good!
I’ve been adding tier rewards to the campaign, as well as profiling different things about Turnover. Be sure to head over there and take a look.
Ok, time for technical devblog post.
Optimizations
Been spending some time lately completing some engine optimization. I knew eventually I would have to get the number of sprite draw calls down, and that would mean I would have to go back and reedit levels. So, being that level work is roughly half finished, I decided I should take care of that before further level work began.
These optimizations had been in planning for some time, but I recently put things aside while I have been tending to the KickStarter campaign.
Sprite Maps
First thing’s first, I started grouping sprites together into separate sprite map images. This means that instead of having 10+ different sprite textures making up all of the walls of a level, I would save them together into 1 sprite map. This means I only have to load 1 texture for the walls instead of 10, putting less load on the GPU. I’ve done this for the walls of the levels as well as the floor textures. Pretty standard stuff.
Tile Vertex Arrays
Now that I had thematic sprites grouped together into textures, I could take things a little further.
Previously, each sprite in the world was a separate entity. This means it had to be loaded, assigned a sprite texture, contained, and drawn. Not too bad, except the floor and walls layers ended being a lot of sprites, sometimes in the thousands, which meant a lot of iterating and a lot of separate draw calls.
So, I changed from using my sprites entities to pushing Quads to a vertex array. What this means is that for each sprite that will be in the world, I create a 4 vertices polygon, which is then pushed to a vertex array object. Each polygon is assigned texture coordinates from the sprite map (see above).
The result: 1 texture load (with multiple “sprite textures” combined into the sheet) and 1 geometric object to draw. This let me cut out all of those draw calls, since everything was combined into one object.
My test of a 512x512 sprite layer (262144 sprites) yielded somewhere in the 35-40 fps range. Converting this over to one vertex array object brought my frame rate up to the 120 fps cap. It also cut my observed CPU usage (via task manager) by ~20. Aside from my collision system, this sprite problem was one of the main performance offenders and I was glad to have finally taken care of it.
Gamepad Support
Analog stick aiming
On Turnover’s Kickstarter campaign page, a backer asked if the game would have gamepad support. Over the last couple of days, I refactored my InputManager class to better handle gamepads, specifically allowing more button support and easier button binding. Now, Turnover plays great with a gamepad.
