The origin story and initial findings

Why target potatoes for your gamedev projects, especially 3d ones? I believe that these potatoes have a lot to teach us. The specs of the GameShell are Quad-core Cortex-A7 1GHz CPU, Mali GPU and a whooping 1GB of DDR3 RAM. I’ve been developing games for such retro handheld devices for quite some time now, they were all 2d and running a custom engine, here’s a few of them:

• Modite Adventure
• Genus
• Evade 2
• Evade
• Boing

As much as I love 2d games though, my heart belongs to 3d, especially the 5th and 6th generation of consoles, so PS1 and PS2. Given that I don’t plan on writing an engine myself, yet nor do I intend on using PS1 SDKs I decided to see if a modern game engine would do the trick. And to my surprise - it did.

When I saw this running on the device I felt the same rush as when I ran my first game using pygame ages ago. The idea that I can develop on my Desktop, in a full-fledged editor and then experience it in the palm of my hands was amazing, although apparently only to me, because let’s be honest the visuals are very basic.

My first instinct was to share this with the community, which at that point had already been running Godot games for a while, but not 3d. The challenge became understanding the tools provided by Godot and the device’s limitation as much as possible.

The core idea of developing for single board computers is that it’s essentially a simulator of developing for retro consoles as you are working with very limited resources and under tight constraints. This is where creativity kicks in.

So what have I learned running this project? Modern ARM CPUs are amazing and with proper GPU drivers they are capable of many things. Even though this demo is currently running at about 40-50 FPS it is rendering around 10-20 thousand vertices and about a dozen of large textures. This means that with proper optimizations you can achieve stable frame rates. On top of that the stock OS that GameShell is running is Debian stretch and X11, the latter is known for being very resource heavy, so I imagine other devices that run under KMS/DRM or Wayland such as ArkOS or JelOS could yield better results out of the box.

Reduced poly count, we’re all aware of low-poly, but nowadays it’s more of a stylistic choice rather than an necessity, for instance one of the assets I was meaning to use for the demo had a single wall block consist of 1000 polygons, that’s about half of PS1’s render budget for the whole screen. Others while being conservative with poly count use textures that are 2 or 3 times larger than the screen they’re being rendered to. To continue with the wall example, you could cut its rendering cost in half by not making it two-sided and skip having top and side faces as well and create a separate model for when that’s needed. Modelling for these devices is a balancing act, as vertex shading is the only viable option, you want to have as many of those as possible if you’d like dynamic lighting to affect your models and on the same hand as few as possible to render at a proper rate.

A texture atlas will help you greatly as opposed to heaving each model have its own texture file, from my tests one of the bottlenecks is exactly that. Try cramming as much data as possible into a single texture file and try using the alpha channel too, don’t let it go to waste.

The amount of optimizations is really driven by the art style and feel of your game. For this demo, I really didn’t have one when I was starting out, I just wanted to try as many Godot features as I could, lighting being top priority, but you can have much better performance if you use unshaded models and bake lighting directly into your textures and then utilize vertex colors as an added effect. The downside is that you won’t be able to easily change lighting in the engine and you’ll have to go back and forth between Blender or any other 3d modelling software and Godot.

Sound, downsample your audio files to the point that they sort of sound ok, because these devices don’t have good speakers. You might want to force these to mono as well if you don’t plan on leveraging stereo effects. I was surprised that 3d audio worked great though, the sound fading as I was moving away as well as shifting from one speaker to the other as I was moving. It seemed like it didn’t have much of an impact on performance.

One of the advantages of using an engine for embedded development is that you have access to tools such as monitors. Godot’s monitor of how many objects are being drawn, their vertex count etc. was an immense help understanding the changes in frame rates. I highly encourage you to not forget about these.

As I’ll continue working on this project, ironing out the kinks, adding support for new devices, I’ll be sharing my findings here.