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
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.
I have heard some people advising the separation of logic and rendering into different threads when making games. Apparently, while rendering needs to happen at ~60fps, logic may only need to happen at ~10fps.
I have a few questions about this:
How can the rendering be faster than logic, if logic is what changes the scene? Surely the rendering thread will be repeatedly drawing the exact same image until the logic kicks in to move the entities around the screen, etc?
Won't this create all sorts of nasty concurrency issues, as the logic and rendering may require simultaneous access to the game's objects?
Can I assume that it's perfectly acceptable to keep my logic and rendering in the same thread? I am using the LWJGL, whose tutorials all seem to suggest a common "game loop" which includes both logic and rendering.
If your game logic does not change the scene, your rendering thread could detect this by giving the scene a dirty flag. if the scene is not dirty, the rendering thread may return the old rendered scene again. Sometimes a scene will change even if the game did nothing due to animated objects like grass, trees or flags.
This will happen because two threads do access the same data. But if the game logic thread processes junks of objects locally and updates those chunks kind of atomically, the concurrent access to the same data should be reduced while processing that data. What I try to say is, do not process the concurrently accessed data in a fine grained way but in a coarse grained way to reduce locking.
In my opinion you should never over-complicate a design if not needed. If you have enough time to process the scene 10-times in a second and to draw it, then you should not use more than one thread. All the older games did it one threaded and it worked. As soon as your game gets more and more complex and one thread can't do all the stuff in 1 / 60 seconds, you may want to use more than one thread to take advantage of a multi-core machine. But you should wait until need be, before introducing many threads.
A sprite may be animating through a series of frames, but no game logic (crash detection, movement, etc) may be required.
You will need to use some form of synchronisation or locking.
It depends how much work your rendering and logic code sections are doing.
How would one go about implementing a mouselistener (or some other way, doesn't matter) that will handle a mouse click event at ANY part of the program? Preferably returning to the line it left off at when the click event handler method completes.
I am using swing. The 'context' is a GUI that constantly updates, but must respond to a mouse click from the user at any time with no delay. Indeed I do have experience with events, using and overwriting their handlers etc., not too in-depth I suppose but what i do know has been sufficient in anything until now.
I could not understand your first para, so my answer goes for your second para, if I understood that correctly. ;)
Swing follows single thread model. So, you should be updating the UI from Event Dispatch Thread (EDT). This thread is responsible for delivering the events to your code too, hence the name. If you are continuously updating an UI in a loop then that is going to keep the EDT busy and blocked. The end effect will be an UI which does not respond to user events. This because the events are getting queued and EDT can pick them and deliver them to your code when it becomes free.
Games typically encounter this kind of scenario. You might have noticed that games typically have one fixed rate of refresh which they call FPS (Frames Per Second). Typically maintaining 60 FPS is good enough. That is, you need to draw your UI 50 times per second, but right now it seems that your render loop (which updates the UI) is running continuously.
You need to have separate thread continuously running which is responsible for drawing the UI. This should draw into a buffer (Image). And then invoke repaint() on the UI element to be updated. That UI element's paintComponent() needs to overridden, so that it can copy the image in Image buffer and paint that on the graphics context.
Now comes the real trick. The loop which calls repaint() must do some arithmetic to make sure it does not go beyond drawing 60 times, i.e. looping 60 times, per second. If and when it does then it must call Thread.sleep(sleepTime), where sleepTime is the number of milliseconds left in a second after looping 60 times. It might happen sometime that your loop may take more than a second to complete 60 iterations, then don't just go ahead for next iteration, but call Thread.yield(). This will give other threads a chance to use the CPU, e.g. maybe your EDT. To make the matter more complicated, do not keep yielding always, so might want to put some logic to make sure that yield for only x consecutive times. This last scenario should be very rare, if at all. This scenario means the system is under heavy load.
Remember, repaint() is thread safe and allowed to be called from any thread. It schedules a paint() call on EDT. So, calling repaint() does not guarantee a paint. So, you may want to experiment with different values of FPS to find the one which suites you.
By the way, the trick of rendering to an in-memory Image is technically called Double buffer. This gives us the ability to render nice smooth animations.
Further reading:-
LANSim - Wrote this code a long time back. You can use this code as an example.
http://java.sun.com/docs/books/performance/1st_edition/html/JPSwingThreads.fm.html
Killer Game Programming in Java - This book is on this subject.
Have you looked at SwingWorker? It's a simple framework that lets you run computations in the background and periodically publish updates to the GUI thread.
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.
I have a little java app to effectively "tail" an arbitrary collection of files defined in an ini file. My "LogReader" class extends JFrame, and does the heavy lifting; reading the collection of file paths into a vector, and then iterating over the vector, reading each file and adding the last X lines of each to a text areas on the tabs of a JTabbedPane. The process of building the vector and iterating over the files is kicked off by clicking a JButton, via an ActionListener.
The reading of the files worked fine (and still does), but the process of reading 20-some files, some growing as large as 30MB, takes some time. To help pass that time, I decided to add a progress screen, which says "Now reading file #3 of 26: c:\logs\superduper1.log", and so on. So I created another class, "SplashScreen", also extending JFrame, and added a JLabel that would indicate the progress. The SplashScreen class has an update() method, which just does a setText() on the JLabel.
The ActionListener on the JButton calls RefreshLogs(), which looks something like:
vctFileStrings.clear();
tpMain.removeAll();
frmSplash.update("Loading Configuration"); //Update the label on the Splash Screen instance
BuildVectorOfLogs(strConfFile); //Read the collection of files into the vector
frmSplash.update("Reading Logs");
ReadLogs(); //read the files, updating the Splash Screen as we go
and then ReadLogs() iterates over the vector, reading the files and building the TabbedPane.
What I noticed, though, is that when RefreshLogs() is called from within the ActionListener, the Splash Screen doesn't update. However, if I add RefreshLogs() to the constructor of the first frame, the splash screen works as expected (updates progress on each file). After some experimenting and reading, I think that I need to create a worker thread that reads the files, while updating the splash screen in the event-dispatch queue.
My questions are:
- Is my thought correct? Is there some simple alternative to implementing threading that would allow me to update the splash screen from the method called by the ActionListener?
- If this would be best accomplished using threading, what scope of the activity would I need to thread? Would I need to put all of the file I/O activities into their own thread? Should I put the GUI activities (label updates) in their own thread, so they occur separately from the JButton click event?
I would say: yes, your thoughts on offloading the reading of large files to a separate thread are correct. You should never perform long tasks on the Event Dispatch Thread, since while that thread is busy, the GUI will be unresponsive, and you application will feel slow.
This sounds like good case for SwingWorker. This class allows you to perform slow requests (such as disk or network access) on a separate thread, with progress updates being fed back to the GUI with the EDT. SwingWorker looks after all complexities of switching between threads. All you have to do is implement your business logic in the appropriate places.
Sun has a tutorial on SwingWorker.
Yes, you should put your time intense reading into a separate thread. Now you do everything in the event-dispatching thread (EDT), which would update your GUI but is busy reading your data.
You can use SwingWorker for this. Have a look at Using a Swing Worker Thread which looks like what you need.
One suggestion for you, to figure out how to do this, and in case you are using NetBeans or have access to NetBeans, is to look at the default Java Desktop Application template. It creates a pre-wired desktop app with progress bar built into a status bar, that will automatically get updated when any "Action" code gets executed. It leverages the Action API which is also pre-wired to run in a background thread.
By looking at that auto-generated code you'll be able to properly and easily implement it in your own.