Wow, thanks everyone for the huge response
This does work but.... it is very difficult to get working, and in my various tests, rarely achieves more than about 10-20% frame rate increase. And then only if you've got a dual-core system: you'll then find that the performance is slightly worse on a single-core system, which last time I looked was still about 25% of the systems out there in the wild. I'd say don't bother doing it if I were you and concentrate on getting it working single-threaded.
Cas
Thanks for the info, I think i will follow this advice.
Nice to see people realize that a computer has more than one core!
The main problem with threading out graphics is that you have to make all OpenGL calls from the same thread, meaning that the graphics thread has to own the OpenGL context. This makes it a little difficult to initialize OpenGL (the Display, e.t.c.) and load textures and shaders, since they also have to be in the same thread. It's much easier to flip it around and thread out logic instead, since you can call OpenGL commands from the main thread in that case.
There are 2 kinds of thread-safe: Either you add synchronization to a normal solution, or you adapt the solution to not need synchronization in the first place. The second one usually has slightly worse single-core performance, but scales MUCH better with multiple cores, since synchronization costs some performance. Separating graphics and logic is pretty easy, but getting it perfect is pretty hard. The logic thread will read and write, e.g. update the game state, while the rendering will ONLY read information to draw stuff. Not much synchronization should be needed, but there is a big problem: The state may change during drawing, which may surprise the rendering thread. Some objects may have data from the last update while some objects have been updated. This is okay for a relatively simple 2D game, but in 3D, this can produce seams in the world!
I made a small library for threading games. In it you're meant to setup Task objects which perform different tasks. A Task has a list of other Tasks that needs to have been completed before it's allowed to be run. The Tasks are compiled into a TaskTree which can be run from a GameExecutor. This allows pretty complex threading to be very easily implemented.
- You can make two Tasks run at the same time by having two Tasks that do not require each other. A multithreaded GameExecutor will put these on different threads. You're not supposed to have any manual synchronization inside Tasks.
- You can also make Tasks themselves multi-threaded by using a SplitTask. For example this allows you to multithread movement updating by updating every other object from two different threads.
You can take a look on it here:
http://code.google.com/p/small-java-threading-library/. Sadly, the interest on this forum was lower than I expected for it (0 downloads so far >_>).
Thanks for the info, I'll take a look at that threading example you made
(although we have already implemented a lot of threading, so I will only read it for advice, thanks anyway
)
How about best of both worlds (pseudocode):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| public void gameLoop() {
boolean isLogicThreadRunning = false;
if(Runtime.getRuntime().availableProcessors() > 1) {
new LogicThread().start(); isLogicThreadRunning = true;
}
while(isGameRunning) {
if(!isLogicThreadRunning)
update();
render();
}
} |
Then just synchronize as necessary
Yeah, I think we'll persue this route, thanks
My engine is multithreaded. I have a game engine thread, the rendering thread and the network threads. For a game that has AI there is the AI threads.
My reason for doing was to separate the screen frame rate from the game turn rate. Turns out that it kinda doesn't work well without a lot of interpolation code on the rendering side. However this still makes the code much cleaner. Most of the work is still rendering so there is not really a performance increase on a mutlicore system in this case.
For synchronization, the engine gives out game state snapshots to the renderer with a thread safe queue from java.util.concurrent. The controller (aka gui in the renderer) sends command objects to the engine which again just uses a thread safe queue. The map, since it does not change, is shared without any synchronization.
Keeping all the opengl code in a single thread was easy enough. You can always use Display.makeCurrent() otherwise.
I find thread programing reasonably easy if you keep the threads coarse and the communication between them simple. Note also that opengl drivers may do things in the background for you too.
I'm not sure using interpolation would be very effective for our game, there is a lot of movement going on, and it's tile based, so I think it would be fairly obvious if a character overshot and had to jerk back in another direction...
Threading should be one of the last things you implement in the game, but you should still be coding with concurrency in mind if you plan on implementing it later. I am making a strategy game, which means that the CPU is a huge bottleneck in AI, line of sight, e.t.c, meaning that threading is pretty much necessary for large maps with many units. I expect an almost linear increase in performance for the parts I plan to multithread using the threading library I made.
We are making a strategy game also, but I feel it is always easier to multithread code while you know it well. If you code it thinking of concurrency anyway, then usually it won't take long to actually make it concurrent, I feel it is more useful to make it concurrent at the time of writing, really.
--------------
Once again, thank you all very much for all of the assistance
