- Joined
- Jan 2, 2020
- Messages
- 1,364
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 androidgame.java 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.
It's all about the file called androidgame.java 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.
Code:
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) {
updateGame();
accumulator -= UPDATE_PERIOD;
}
renderGame();
}
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() {
@Override
public void run() {
while (true) {
renderGame();
}
}
});
renderingThread.start();
}
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.
