Blog

Performance choices in Xentu

Posted: Sun 8th of October 2023

header image

The Xentu game engine does a lot to try to get out of your way when it comes to performance. It does some initial setup when your game starts based on the game config you create. Boots what's known as a "machine" which is like an interface between your game code and the engine (one per programming language). Then executes your game code, thereafter sending events when you need to update some game logic, or draw the next frame.

This means a lot of the time, performance comes down to things you can control. In this article I'd like to explain some things you should consider when building a game in the Xentu game engine. And provide some opinion on which I think will work for specific scenarios.

Programming Languages

I get asked frequently why Xentu has more than one language option. Here is one of the reasons. Picking programming language can have a large effect on how well your game performs depending on situation.

For example JavaScript is the only language that does not get compiled into bytecode. This means on average it's about 1/3 slower than both Lua and Python. So for fast paced games, JavaScript is probably not a good fit. But if you don't have a lot going on at once, or you limit your framerate to compensate for the bottleneck, JavaScript can still be used effectively.

Viewport Resolution

The viewport resolution allows you to decide the resolution of the canvas you draw on. The viewport is then clamped, centred, or stretched to fit the window. This can have a dramatic aesthetic impact on your game (making a really pixelated one for example), it also has implications for performance. A smaller viewport will require less to render, while a larger viewport will require more.

V-Sync

This widely mis-understood option can be enabled/disabled in your game.json file. When enabled, your graphics card attempts to limit the number of frames drawn to the screen by your monitors refresh rate. Which means if you produce 90 frames in a second, but your monitor can only do 60hz, only 60 of those frames will be sent, in theory stopping screen tearing from happening.

In theory this option should not have any effect on the performance of your game. But if you are trying to run things intentionally faster than your screens refresh rate, then having this enabled may hamper your efforts.

Update & Draw Tick Frequency

Xentu gives you control over how often you'd like the engine to request logic updates, and draw calls for the game. The update_frequency and draw_frequency options determines the interval between the update/draw events being fired. The draw_frequency option is slightly different as it's the only one that can be turned off with a value of 0, and if the value is the same as update_frequency then it's cycle will lock to the update cycle.

Logic updates can be a hinderance on draw calls, as drawing usually needs to be done a much higher frequency, however this is situational. Like in the programming language part, if you are limiting yourself to say 30fps or lower, you may not notice.

If you find that performance is greatly impacted by updates. Consider enabling v-sync, then unlocking the framerate by setting draw_frequency to 0. Or try lowering the update_frequency to perhaps half your draw_frequency.

Batching Draw Calls

You get full multi-layer sprite batching in Xentu, which means most of the calls you make get sifted into job lots tagged by texture to be sent to the GPU for rendering. The sprite batch mechanism can be exploited for performance by grouping textures into larger textures before loading. There are mechanisms built into Xentu that utilize this, such as the tile maps and sprite maps systems.

To take full advantage, consider how you group draw calls between renderer.begin() and renderer.present(). You may find using less layers, or consolidating textures into a texture atlas nets you more performance when displaying a lot of graphics.

Conclusion

There is a lot of literature already on the subject of making games run faster. In this article I really just wanted to highlight certain aspects that relate specifically with Xentu. I hope what I've talked about here has been of use, and thanks for reading!

Koda