Performance choices in XentuPosted: Sun 8th of October 2023
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.
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.
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.
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
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
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.present(). You may find using less layers, or consolidating textures into a texture atlas nets you more performance when displaying a lot of graphics.
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!