Libgdx How to task/thread/wait the start of the screen.

Hello friends.

I’m confused about a little issue. I’m finishing my game and I found a problem, when I start the Menu Screen/Game Screen I have a delay (only on Android) until everything start to run properly.

E.g: When I switch to the Game Screen I need to start in “pause state”, so the player can start the game itself manually when he feels everything is “loaded”. My character has a constant move (horizontal), so if I start the game directly, the player can move for some milliseconds before the player start the game itself.

I really think it can happen because I separated the Draw code and Calculate code inside of render(). The draw() is ALWAYS running and the calculate() is running inside a FPS independent movement code, this is great because I have the same movement speed when 10/20/30/60FPS, but in theory when the game/any_screen starts, the calculate() runs normally in the first frame and this is why the game “starts” few milliseconds before my device show me. In the Desktop version this is not perceivable because CPU/GPU/Memory is very fast.

My code is simple and always the same:
- Show()/Create(): stage, batch, viewport, initialize some variables…
- Render(): RunningState(draw, calc), PauseState(draw, calc).

I want to wait everything be loaded before render(), but in theory render() is only called after show()/create(), so my game is working properly, but how can I start the game itself or the calc() only when the device is prepared to run?

Other e.g: In the first screen, a logo appears with fadeIn-fadeOut, when I start the game on my Android device, I usually can see only the fadeOut or at least the end of fadeIn.

The calculation/game logic should always be framerate-independend. This can be done by mulitplying the speed of the entity with the delta. The bigger the delta, the bigger the movement your entity makes. But always keep “tunneling” in mind, cause for verry low FPS one movement could be pretty big and the entity could tunnel through objects he should collide with.
Solutions would be to limit the delta to a minimum (for example 1/30, FPS < 30 would behave like FPS = 30) or to use continuous collision detection.
If you don’t like this solution and want to keep calculation and drawing like you are doing it now, you could simply start the game in a paused state.
That means you need to keep a boolean pause and only calculate/update the logic, if !pause.
You could then simply start/resume the game, when the user touches the screen.

An easy solution would be to throw away the first frame (just render a black screen), and start everything running on the second frame.

This really works great, but I still need some improvements… I’m using “pause state” before game screen =/.

Right now is okay and visible, thanks!

Here is the final game, I released the final version today: