X@COM

The game has always been a bit demanding on older computers when sub-windows are open (it causes those funny graphical anomalies you see with the text and borders), and I figured now was a good time to deal with that.

Of course the first option that comes to mind is... hardware acceleration! So I spent the previous weekend attempting to integrate OpenGL into Rogue Engine X. It sure brought back memories of the times I used DX9 in years before, trying to figure out what the heck was going on in the background when all I wanted was some simple result. Several days later, after fiddling with OpenGL and pulling my hair out, I pulled the plug on that idea.

After all, this is a 2D game, so using the GPU shouldn't be entirely necessary.

Approaching the problem from a different angle, I decided to profile the game code itself and look for bottlenecks. (Bonus: I learned of an awesome application profiler called Very Sleepy--so easy to just attach it to a running program and go! And it should perhaps be called "Very Fast", because it really is. Before I was always copying the source over to my XP VM and testing it with a very old profiler.)

As suspected, the engine code handling preparation of the screen data to be sent to the renderer was eating up a majority of the processing time. It was using a method I called "drill blitting", checking for all screen objects positioned over a single cell and blending them together to create the screen's final appearance at that location. It was the easy way to write the code back when the engine was first created, but the game has become more complex since then with lots more objects to handle. So I completely re-thought the way the screen is drawn and switched from cell-wise to layer-wise blitting, merging one horizontal layer at a time rather than doing it cell by cell.

Hell yeah!

This was tested on a full-sized, fully-revealed Rookie's Tale map using the default font, the first time with just the default map view open, and the second with a simple inventory open on top of that.

As you can see, the more window objects on the screen the bigger the savings, so opening the inventory and other sub-windows won't cause as big a hit to the FPS as it used to. FPS used to take a 23% hit while the inventory was open; now reduced to only 3%! (We're definitely going to need this boost, because the new UI will have a lot more little windows and interactive parts.)

Obviously your actual FPS will likely be lower unless you've got one of these wicked core i7 chips (or whatever better stuff has come out since). I captured those shots from my title bar FPS readout (F5), but you won't see values this high unless you uncap your FPS (Ctrl-F5).

I'm guessing it's possible to improve on this even more with some tricky OpenGL shaders, but that's beyond me--we'll be sticking with software rendering for the foreseeable future.

As there always is with any rendering WIP, there were several blooper-worthy screenshots (from the OpenGL attempts).

Rookie's Tale intro, as written in alienscript.

Complete mess.

More alienscript.

Inversion of foreground and background colors.

These were the fun ones. The most annoying, and prevalent, screen was the seizure-inducing flashy yellow one. Ouch my eyes!