A game is in development, and I’d like to introduce it—I think it’s entertaining.
When the program starts, we see a match in progress. You can join the game, and you’ll randomly take control of one of the balls. Controlling the ball is based on a very simple principle: you either turn right or left. You can control it using a touchscreen or by tilting your phone left and right.
In the menu, you can see performance metrics displayed at the bottom. The first metric shows how many times per second the positions of players are recalculated. Since I didn’t use delta time (which would have been too complex), I set it to 58 recalculations per second. This is the primary thread, and it must always maintain this rate. The speed of the balls does not change. Rendering has a secondary priority and runs as fast as the phone allows. This setup ensures that even if the visuals are fluid, physics calculations won’t slow down. Physics comes first! I aimed for both metrics to reach 58 FPS on my Samsung Galaxy A13. (It’s 58, not 60, because I’m unsure how OpenGL synchronizes with the phone’s display. Specifying 60 would be pointless if I can’t guarantee all 60 frames are shown.)
The key takeaway is that the game should theoretically maintain 58 FPS even on lower-performance phones. However, on my Xiaomi Redmi 12, the SoundPool library occasionally causes stuttering. This is noticeable when there are many sound effects, leading to dropped frames. I’ve been exploring solutions for this, such as using callSubDelayed with SoundPool, which slightly improves the situation but isn’t perfect. I plan to use threading for sound playback in the future.
I’m looking for OpenGL-specific answers, testing suggestions, and feedback.
The program is available for download, and the necessary libraries (OpenGL and threading) are included.
Unfortunately, the recording is weak, low fps, choppy.
Gameplay:
The gameplay is simple. Every ball wants to catch “something.” The player holding this “something” needs to bring it into the tornado. Whoever manages to bring it into the tornado wins. Once the ball is inside the tornado, the tornado ejects it far away, and the game starts over.When the program starts, we see a match in progress. You can join the game, and you’ll randomly take control of one of the balls. Controlling the ball is based on a very simple principle: you either turn right or left. You can control it using a touchscreen or by tilting your phone left and right.
Technical Design:
One of the primary goals was to make the game run at 60 FPS. Since the game involves high-speed action—flying, jumping, drifting—it’s crucial to deliver at least 60 frames per second for a smooth experience. Another key goal was to ensure the game runs on a Galaxy A13, which is a very basic phone. If it performs well on this device, it should run smoothly on many others.In the menu, you can see performance metrics displayed at the bottom. The first metric shows how many times per second the positions of players are recalculated. Since I didn’t use delta time (which would have been too complex), I set it to 58 recalculations per second. This is the primary thread, and it must always maintain this rate. The speed of the balls does not change. Rendering has a secondary priority and runs as fast as the phone allows. This setup ensures that even if the visuals are fluid, physics calculations won’t slow down. Physics comes first! I aimed for both metrics to reach 58 FPS on my Samsung Galaxy A13. (It’s 58, not 60, because I’m unsure how OpenGL synchronizes with the phone’s display. Specifying 60 would be pointless if I can’t guarantee all 60 frames are shown.)
The key takeaway is that the game should theoretically maintain 58 FPS even on lower-performance phones. However, on my Xiaomi Redmi 12, the SoundPool library occasionally causes stuttering. This is noticeable when there are many sound effects, leading to dropped frames. I’ve been exploring solutions for this, such as using callSubDelayed with SoundPool, which slightly improves the situation but isn’t perfect. I plan to use threading for sound playback in the future.
Visual Effects:
The game features smooth lighting effects. There’s a light source (moon or sun), which casts realistic shadows on everything.OpenGL-Specific Questions:
- Distance-Based Alpha Transparency for Textures:
In the game, distant terrain generated using Perlin noise pops into view abruptly, which is distracting. It would look much better if the textures faded in with alpha blending. One approach is to pre-generate multiple alpha versions of the terrain textures, but that’s inefficient—requiring more memory, pre-calculation time, and results in choppy transitions if the fade distance is short. I’d prefer an elegant, OpenGL-supported solution. Any suggestions? - Rendering the Tornado with Z-Buffer Issues:
I wanted the tornado to always be visible, even from a distance. However, the rendered scene ends where the visible terrain does. (Why not increase the render distance? Because increasing the rendering range isn’t recommended due to Z-buffer resolution limits.)
To address this, I scaled the tornado proportionally to its distance. While it appears distant, it’s actually rendered nearby. It’s a hack and feels unnecessary. Z-buffer toggling would solve this, but I’ve encountered issues with OpenGL ES: enabling and disabling Z-buffer tests and writes can’t be separated—they occur simultaneously.
Here’s the problem:- If I disable the Z-buffer, I can draw something that’s always visible, but it doesn’t write to the depth buffer.
- When I re-enable the Z-buffer, subsequent objects overwrite it as if it’s not there.
- This limitation feels unnecessary. I spent an entire day trying to solve this and grew frustrated with the removal of this functionality in OpenGL ES, likely due to optimization on modern systems. Has anyone faced this issue and found a workaround?
I’m looking for OpenGL-specific answers, testing suggestions, and feedback.
The program is available for download, and the necessary libraries (OpenGL and threading) are included.
Unfortunately, the recording is weak, low fps, choppy.