D2 log 051 – Fixing my timestep

In Superforce, it was safe to assume that the game would run at a constant rate of  60 frames per second. This was thanks to

  • predictable hardware and software environment
  • fast, simple rendering and game update logic

The game logic could thus be directly locked to the framerate. This assumption is not valid for Devastro 2. I have no idea what machines it will run on. I don’t even know if VSYNC works on all of them.

There’s a great article called “Fix your timestep” which describes a good way to decouple game updates from rendering.

After making a few changes in my code, I have indeed fixed my timestep. Toggling VSYNC causes a big FPS increase and yet gameplay keeps running normally.

I was not able to fully implement the last step from the article, which is interpolation. It would require more substantial changes to the game and I just didn’t have time for that. I may or may not do that later as the… next step.

I might add interpolation for the camera position, which could smooth things out even more without too much work.

Raspberry Pi

Recently I purchased a Raspberry Pi. I wanted to try building & running Devastro 2 on it. Would it be fast enough?

I got the the Raspberry Pi 4 model B with 4GB of RAM. It’s a cute little device. Packaging and branding are top notch. Installed the official Raspberry Pi OS. It works.

Raspberry Pi Imager

There were a few things I had to adjust in my code to make it build with the default clang 7 compiler.

Unfortunately I couldn’t get the game to run. There was some mysterious problem with the OpenGL drivers and I couldn’t figure it out. Running out of time I had scheduled for this experiment, I decided not to pursue this any further. The Pi is sold and I’m focusing on the other platforms.

It would be great to have a simple game focused OS for the Raspberry Pi.

All it would do is run games directly on the device, with no setup required and without any interference. I could distribute a bootable image containing a copy of the OS and my game. It would be guaranteed to work on every Pi, every time.

  • Console only (no X server or other GUI)
  • OpenGL driver (or Vulkan)
  • Audio driver
  • Game controller support
  • SDL support
  • Not necessarily Linux based

When I see the new 400 model I think it is clear that an official Raspberry Pi notebook is also in the cards and I’m looking forward to that. However for my game I need the software part to improve as well.

D2 log 050 – Cinematic mode

New feature: cinematic mode.



Sometimes a quick non-interactive event will run in the game. I want to make it clear to the player when this happens. Adding the black bars still seems like a reasonable way to do it.

There’s also some new code for camera panning & zooming between different targets and smoothly blending those transitions with mouse look.

D2 log 049 – Screen navigation stack

I’ve implemented a navigation stack for screens in the game.

It used to be that when I would press “Play” in the main menu, the active screen would be changed to the episode selection screen. After pressing “back” there, it would say “open main menu” to return. All screen transitions were hardcoded in both ways like that.

Now when I press “Play”, it pushes the next screen onto the navigation stack. The “Back” button on the next screen doesn’t need to know where to go back to. It just tells the navigation controller to “pop” from the stack. The connection is now only one way and that makes it much easier to add new screens or change the order they are presented.

There are a few special cases, such as cutscenes, which effectively disappear once they are done. Other than that, the system is really simple and it only took an hour or so to implement, including the debug window shown above.


D2 log 048 – Load time improvements, pt.2

I did some more loading optimizations.

Last time I managed to make nice improvements by using multiple threads. As I’ve been adding more and more assets, the load time has crept up again since then. 

This time I did two things.

Instead of decoding all PNGs and cropping them on each start, I do it once and write the result to disk as cache. Next time I just compare timestamps and load the processed image directly. This is much, much faster. The final release will have only the processed images in a PAK file.

Second, I profiled the startup sequence and found that a lot of time was spent building fonts. In particular, it was the Material Icons font, which isn’t even used when the game is run normally – it’s only for editor icons! I wanted to keep dynamic loading for the other fonts so I just replaced the few icons I actually needed with prerendered bitmaps and got rid of the icon font.

Loading times are really quick again which makes iteration much more pleasant.

D2 log 047 – Sentry turrets

New graphics for a static enemy unit that’s actually been in the game for a while.
Do not touch. It gets angry!

The sentry turret is a big chunk of solid cold steel. When it smells danger, it gets mad. We don’t know how it works. The aliens probably don’t know it either. They just place these things around their camp site to keep them safe. Except they don’t, of course, because you brought grenades with you. Right? Right!?

D2 log 045 – Episode selection screen

Finishing the episode selection screen. Made a new Blender cover template, where each episode has its own scene and a single export command puts everything in the game.


Dots below the posters represent levels, filled ones are completed.

With the code & pipeline set up, I can focus on the content.

The missions in the first game were kind of all over the place. This time I’d like each episode to have a central theme with specific objectives to be completed over the course of 3-5 missions.

Q&A

  • Is there going to be an stealth mission? Haha, no, sir. We’re going loud.
  • Escort mission? Forget it.
  • How about a mission with a farmer driving a tractor and you sitting in the trailer and shooting things? Why not.
  • Do you need to get said farmer some beers? Yes!