Trying to understand Android implementation


Well-known member
3rd Party Module Dev
Tutorial Author
Jan 2, 2020
I'm trying to analyze the whole Android platform for Cerberus (it is around 800-900 lines of code so it feels not impossible). But as I do not have very much time i asked our dear GPT4 to analze th whole thing and found abs no problems with timing or anythign but except one place. I finally got an suggestion how to change it. Maybe it can give clues how to improve the last bits that could be improved on Android. It seems to work exctremly fine otherwise.

It's all about the file called code. . and we are discussing how improve render to be smooth grapphics like libgdx.

Ever other implemtnation in Cerberus-x is absolutely perfect it seems. MSAA config still sets 565 for some reason but that's another matter I guess.

Here are the steps to transform your existing code into a structure that follows the suggested timing and threading approach:

Step 1: Remove the Thread.sleep() calls:

Remove the Thread.sleep() calls in the rendering loop (onDrawFrame() method) since they can cause frame drops and inconsistent frame rates.
Step 2: Introduce a game loop with a fixed time step:

Define a constant representing the desired update rate, for example, private static final double UPDATE_RATE = 60.0; (adjust the value as needed).
Calculate the update period based on the update rate: private static final double UPDATE_PERIOD = 1.0 / UPDATE_RATE;.
Remove the _nextUpdate and _updateRate variables.
Introduce a game loop that runs continuously, updating the game logic at a fixed time step.
Track the elapsed time since the last update using System.nanoTime().
Use a while loop to ensure that updates are performed at the desired rate:

long currentTime = System.nanoTime();
double accumulator = 0.0;
while (true) {
    long newTime = System.nanoTime();
    double frameTime = (newTime - currentTime) / 1_000_000_000.0;
    currentTime = newTime;
    accumulator += frameTime;

    while (accumulator >= UPDATE_PERIOD) {
        accumulator -= UPDATE_PERIOD;

Step 3: Move rendering to a separate thread:

Create a new thread dedicated to rendering.
Move the rendering code to the new thread, using a rendering loop that continuously renders the game state.
Use appropriate mechanisms to communicate between the update thread and rendering thread to ensure data synchronization and thread safety.
Here's an example of how you can structure the rendering thread:

private Thread renderingThread;

private void startRenderingThread() {
    renderingThread = new Thread(new Runnable() {
        public void run() {
            while (true) {
Step 4: Synchronize data access between threads:

Since you now have two threads running concurrently (update thread and rendering thread), you need to ensure proper synchronization when accessing shared data to prevent data races and inconsistencies.
Use synchronization mechanisms such as locks (synchronized keyword), semaphores, or concurrent data structures to handle shared data access safely.
By following these steps, you'll have a structure that separates the game update logic from the rendering, uses a fixed time step for updates, and runs the rendering in a separate thread. This approach helps avoid issues caused by sleeping in the rendering thread and provides a more reliable timing mechanism.

Note: The provided steps outline a general approach, but you may need to adapt them to fit your specific code structure and requirements.
By using SetUpdateRate(0), it will never hit the .Sleep statement. But I guess you are doing that already.
Yes I do use that, I was too quick I need to learn more about the structure of Cerberus-x, Libgdx and Android System.

I was surprised that Android target uses 565 but again maybe there is more code I was just looking into how it trie to check if the device supports MSAA, it tried to use 4, then 2, then none. But the two is commented away so basically it's just MSSA 4 or none. But it only picks 565 which seems very old to me. Even my Android 4.4.4 uses RGB 8888 wihout any issues.

But I need to dive into the code and get aquinted to how it all works. it is impressive that the Android platform target is about 800 lines of code. So I feel there's hope.
And then you have ther native mojo code or the mojo2 translation. Plenty of stuff.
I know.. I was hoping that I wouold not need to go that deep as all the other platforms works great
Will at least try to keep the common code out of this as long as I can.

It can be as simple as Mojo1 is better performance in Android bc GLES 1.0 uses 565 RGB so it does not constnatly remap, even textures in the wrong format internally has the potential to make things slower inside the GPU. But this is just oneof the ideas I have to test and go though. It needs to happen in steps.

Right now I'm trying to understand how Libgdx does it on Android but I'm buzy with getting my first app in the stores.
Good luck
It's great that you investigate in that!
I'd propably also try using Chat GPT to get some hints, but instead of presenting the engine code I would rather use a minimalistic game in transpiled java code so it kind of shows how the pieces work together as a whole.
Good luck from me as well!
Thanks, a tips when using Chat GPT4 when you need it for big codes is to tell it that you will provide it code in x chunks of 200 lines (i dont know the exact limit but 800 loc was too much at one time), and it will kindly wait while you feed it, and thenl start analzying and work the complete code with you. It works great.

Again, thanks!

Also thank you both for keeping Cerberus-X alive.
Top Bottom