I decided to convert my spritesbased 2d game for android to use opengl-es to help with some render-related framerate issues. Currently the setup is as follows:
Rendering tkaes place in its own thread, with rendermode set to continuous. Game logic updating takes place in a seperate threaad. Both threads interact with a synchronized drawlock class which ensures that they are never touching the game information simultaneously.
So basically, the render thread waits for any current update to finish before drawing and the update thread waits for the current render to end before starting an update. Everything looks great except or some choppiness I've noticed in the picture when moving around the screen.
I believe this is likely due to a lack of consistency in the number of updates that happen in between each render, on average twice as many updates happen because as of right now not a whole lot is happening in the update. But this lacks consistency so sometimes 1 gets through, sometimes 2, 3 etc so the delta in positions of items being drawn is also not consistent thus creating the choppiness.
Anyone have an idea how I might rectify this? The update thread is regulated to 60 times per second with sleeps...maybe something similar needs to happen under render? I'm just not sure at this point.
Depending on how voluminous your game data is, you might try replicating it. While the game engine is updating one copy, the rendering engine is working off the other. When an update is finished, the rendering engine switches to reading the updated copy while the game engine waits until the updates are transferred to the older copy (which the engine will then update on the next cycle). It's kind of a double-buffering approach, but applied to the game data instead of to the display buffer.
Related
I made a relatively simple structured Android game that could quite easily get away with updating the game logic and doing the rendering all inside the onDrawFrame function in the render thread of the GLSurfaceView. However, thinking of future projects I have begun to explore multi-threaded options, including running the main game update logic outside of the rendering thread, which is what replica island did. There is a blogpost about it here: http://replicaisland.blogspot.co.nz/2009/10/rendering-with-two-threads.html
Resources such as the replica island source code (https://code.google.com/archive/p/replicaisland/source) have been helpful in understanding this double-buffered render-command-registering multi-threaded renderer idea. The game loop updates objects and those that want to be drawn register themselves in the not-currently-being-used buffer. That buffer gets swapped at some point and the renderer works on those render-commands to draw them using opengl.
There are some things I am not really understanding yet.
The replica island game thread loop (GameThread.java) starts with a block waiting for the renderer to stop rendering (mRenderer.waitDrawingComplete) . It then updates the game logic, and then swaps the buffers. Swapping the buffers notifies the renderer to start on the next batch. When the renderer is done the game loop will update again, and so on.
This approach doesn't seem to run the game logic and the code that loops over the render objects in parallel? They seem to operate in lock-step, and derive their performance boost from the game logic not having to block while opengl actually finishes the rendering after the onDrawFrame function is finished.
I tested similar code and this is definitely faster than just single-threading it all when there is a large amount of stuff to be drawn. However, because the render loop does not loop over objects while the game thread is also working with them, there doesn't seem to be any inherent need to have the multiple render command buffers. From what I can read of it (and I am guessing I am mistaken somewhere) the game update is not actually updating the 2nd buffer while the renderer is using the first. If that is the case then why have two buffers at all?
Why is the game thread waiting for the renderer to stop drawing before it does its update?
Doom 3 does the same thing: process all of app input and events, then kick off a separate thread to run and draw the next frame while submitting the previous frame to the render system. Then, it waits for the Game Thread to return before swapping the buffers.
Both Threads are designed to use a specific buffer frame, the render or the draw frame. Because they are confined to a specific buffer you don't need to use mutexes or synchronization primitives to control access. Waiting on the thread is the synchronization.
It also keeps rendering and drawing in sync. You are already rendering a frame behind, and want to keep the lag to a minimum. Only drawing a single frame ahead means that your interpolation code is closer to elapsed time and only needs to emit render commands once per render frame. (As opposed to constantly blasting out frames and letting the render thread drop/skip).
Why is the game thread waiting for the renderer to stop drawing before it does its update?
The render system is a state machine, one that you can't concurrently execute commands against. Draw emits render commands that can be executed asynchronously on the other thread. Draw sends them and forgets. It doesn't care about the state or what happens to them. This is async.
Switching the window mode from fullscreen to windowed, changing surface resolutions or generally any other render state update needs to fully execute before continuing (synchronous or blocking) and must be performed with a know API state. These and other updates might affect Draw states, window states, etc...
So the wisdom is to perform event processing and update() on a single synchronized thread so we can block when we need to and change anything that affects states (any state). Then split off and issue render commands on the draw thread and execute the previous set on the render thread.
It is the first time I want to write a java game, and I chose to do a Snake Line.
I learnt from a piece of source code from online. It updates the game states and displays in one thread. I changed around that code, and when I changed the FPS (from 60 to 30), animation slows down. More to this, the game behavior changes too. It is duck shooting game, and the space between ducks get narrower.
So I decided to separate the game thread and the display thread to avoid the above problem. But then I realize it brings out the concurrency problem which will be all over the place.
So as the title indicates, is it good to separate game thread and display thread? What is the common practice and why?
From the changes you experience, it sounds like you are using frame as a unit of time measurement. Or, more precisely, you use pixel/frame(or something like that) for velocity and second for time.
This might be OK for a simple game like yours, ones that are light enough on the system resources so that the delay between frames you specify in the code is practically the same as the real delay, meaning you are in complete control over the FPS. When the game get heavier and modern systems can no longer guarantee that property, you have a problem.
The solution is usually not to separate the game and display loops to separate threads, but to not use frames as unit of measurement for game mechanics calculations. Instead, each frame measure the time from the previous frame and use that value for the calculations, eg. multiply it by the speed to know how much to move a game object in this frame.
Not that separating those loops is such a bad idea. You don't get concurrency problems "all over the place", since the interaction between the game logic and the display shouldn't be "all over the place". The interaction should be one-way: the game loop writes data and the display loop reads it. That means you shouldn't have race conditions, but you can still get other multithreading hazards, which you can solve with volatile variables.
I have recently learnt that jMonkey operates on only a single thread which is its openGL render thread. However I'm not able to understand it completely. I can understand that it executes all update and initialize() calls on a single update loop but input should be independent of this update loop, otherwise it will become a polling mechanism.
What exactly happens when the jMonkey application starts. Three tasks that it needs to do is run a update loop, run initialize methods of app states once, do rendering and constantly cater to events? How does it manage all of this via a single thread?
What happens when I add a new app state in the initialize method of another app state?
In input handling input manager notifies the various listeners about events. How are nifty callback events say onClick() are handled on the same render loop?
Lastly in which order this listen- update-render loop runs and where we can find code related to it?
jME uses an approach that's very common in a lot of game engines (and also used in some other user interface libraries such as Swing).
Everything that the game engine does is done in one thread. This can be called the LWJGL thread but as jME can work with alternatives to LWJGL it's more generic to call it the Render Thread or just the jME Thread.
Everything is indeed done on the Render thread, and it does indeed use a polling mechanism. For example if you are holding down the "left" key then each frame the relevant control or app state will be called on the render thread and will move you left by an amount modified by tpf. Tpf is time-per-frame and is very important for keeping smooth movement and letting game systems run at the same speed independently of frame rate.
The only thing within jME3 that commonly uses a separate thread is the Physics Engine. That has a thread that it uses for doing the physics updates and then changes are pushed through to the Render thread using appropriate mechanisms. The system handles this for you though so it is not something you need to worry about.
The thread runs around a game loop. Each time around the loop it checks for things it needs to do (like enqueued tasks, initialize app states, render, etc. It calls update in each active Controller and control, etc). Once it has finished updating everything it then goes on to perform the render. All of this happens every single frame, but computers are so fast that it can still handle all of that and render the game at good frame rates.
That's an implementation detail that you shouldn't need to worry about except to know that it will definitely work. The adding actually gets queued up and handled in the next frame I think.
Everything is handled from the same loop. jME calls through to Nifty to allow Nifty to do its processing. As part of that processing Nifty detects the events and fires off the callback. This means that the callbacks are already coming in on the render thread so you can safely modify the scene graph. jME uses some specially written collections such as SafeArrayList to allow you to modify the scene graph at the same time as iterating over it.
Update, Render, Update, Render, etc. Events firing generally happens as part of the update process when an update is detected. To find the code start by looking in the Application class, you should be able to find the main game loop in there by tracing through from the start() call.
The jME3 Threading Tutorial covers a fair amount of this:
http://hub.jmonkeyengine.org/wiki/doku.php/jme3:advanced:multithreading
I'm still working on moving my android app over to OpenGL and i'm once again having an issue.
I have gotten to the point where everything FUNCTIONS, the only problem is that the animation seems a little juddery.
I'm monitoring the frame rates and seeing that the drawing thread isn't slowing down, but every once in a while, the main loop slows a bit and I suspect I'm having a problem I was worried about.
The way the app works is that as new objects (say for instance, enemies) are created, 2 objects are actually created. The first one is created and mapped in the main thread, and then in it's constructor, it creates a mesh object which is then added to a group to be drawn continuously by the renderer.
Every time an attribute for the object is changed, (such as its coordinates) The object relays the necessary command to its mesh counterpart (in this example to translate the mesh.)
It was suggested that this was thread safe communication, but i'm having my doubts. I also notice a greater amount of frame skip when new objects are created, I can fix this somewhat by reusing the same mesh object for identical Game objects, but I don't believe this will fix everything by itself.
Can you think of a way to make this more efficient and thread-safe?
Another possible solution: The game logic does not HAVE to go at full speed (realtime) I have it actually set up so that no updates are made untill 33 millis pass. So obviously, I should have plenty of time between frames to draw, can I set it up so that draw is only called on command in the thread (after the game logic has been updated)?
It looks like you need something like a ScheduledThreadPoolExecutor.
With one of these you could put your renderer on a schedule so it executes at 30fps leaving your main/control thread to do whatever it needs to do to the object map between frames.
I don't think you need any wait/notify interlocking as all you really need is to block access to the map while the renderer is walking it. To do this you just need to make the map synchronized. As this will only happen once every 1/30th of a second you are certainly not introducing a significant overhead.
Your main aim should be to put as little unnecessary load on the CPU as possible, this is the key to smooth multithread work. Try to spend as much time as possible either sleeping or blocked.
Added
I subtract the time it took to loop from 33ms, and use the result to specify the length of sleep().
I wonder if that may be part of your issue. On a Windows machine you often get a 15ms resolution on the currentTimeMillis so your sleeps may end up hardly sleeping at all. It may be worth experimenting with a ScheduledThreadPoolExecutor just to see if it improves your timing. ... oops ... this is Android isn't it. Still ... it may be worth a try.
I'm writing a game in Java. And, oh wonder, i have performance issues. I benchmarked the paint itself - 1000 cycles in 3 ms tops. The game logic is even below that. So far, so good. But i still encounter an annoying lag: When scrolling, when zooming, when clicking. The problems get worse when i zoom in and more objects are placed. But still - even when I loop the painting a 1000 times the lags stays more or less the same, so that cant be it.
I tried putting the loop in a task - still the same. I tried pausing the task in between paints - still the same.
Animations run as smooth as silk (since the framerate is stable and high, that makes sense). So how on earth do i organize the inputs in an orderly fashion? Put them all in a seperate thread?
Any input would and will be greatly appreciated!
It sounds like you're using listener callbacks directly on the Swing Event Dispatch Thread, where the UI updates are being done. You should use a command queue, and put events on the queue when a callback is invoked, with the nature of the command, then you use this in the main game update loop that has nothing to do with the EDT.