Im planning to create a 2d game and i am very interested in using multiple threads in my game.
I just want to know what parts of the game that is good (if not necessary) to be used in threads.
Game multithreading
You might as well ask in what parts you should use OOP and what parts don't need it. It depends on a lot of things.
Games that are heavily dependent of CPU time for both graphics and physics/logic/AI/etc. will benefit from having a dedicated graphics thread that draws objects at positions and states specified in one buffer while the positions for the next frame are calculated into another buffer. When both are done, the graphics thread can operate on the buffer the physics thread just updated, and the physics thread will updated the other.
I don't know too much about other techniques, but i consider this a minimal one. You can also just thread specific procedures if they lend themselves to parallelism.
Tell us more about what you're doing and we can give more specific advice. If you're going to ask a question this generic, might as well just google it instead.
Games that are heavily dependent of CPU time for both graphics and physics/logic/AI/etc. will benefit from having a dedicated graphics thread that draws objects at positions and states specified in one buffer while the positions for the next frame are calculated into another buffer. When both are done, the graphics thread can operate on the buffer the physics thread just updated, and the physics thread will updated the other.
I don't know too much about other techniques, but i consider this a minimal one. You can also just thread specific procedures if they lend themselves to parallelism.
Tell us more about what you're doing and we can give more specific advice. If you're going to ask a question this generic, might as well just google it instead.
You probably don't need to use threads. Doing so could make your game very buggy and hard to develop, while adding very little in value. Unless you are using this game as a way to learn complex multi-threading, I would advise that you build your game without threads. The majority of 2D games are not processor intensive enough to justify the additional work involved.
Definately don't go into threads, until you really have to or really want to (experimenting?). It's an absolute nightmare to debug and although as such they don't just "introduce" bugs, they do have a tendency to result in a less predictable behviour than fully sequential code, making it really hard to trap bugs. However, if you get to a stage where you are producing a major game, especially for consoles, it's essential to divide work into threads. Most common division is to dedicate an independent thread to specific subsystems, including game logic, ai/scripts, graphics, physics, audio and networking. This way you might still encounter synchronisation issues, but it's possible to effectively maintain and debug each of the systems individually.
Multi-threading is pretty complex and you'll probably find you'll spend all your time trying to debug the threading and not making progress on the actual game. Much better to have a finished single threaded game. Especially for a 2D game, it's doubtful you'd be pushing the cpu hard enough that you need multithreading.
If your goal is to actually learn multi-threading, and are prepared for the pain, the parts that are typically split into separate threads are things like user input, rendering, physics, loading data from disk and possibly the sound system. You'll want to identify which parts of the code don't rely on each other too much and can be run concurrently.
If your goal is to actually learn multi-threading, and are prepared for the pain, the parts that are typically split into separate threads are things like user input, rendering, physics, loading data from disk and possibly the sound system. You'll want to identify which parts of the code don't rely on each other too much and can be run concurrently.
Almost certainly won't be needed for your game, but it all depends on what you want to do with your game.
If you're looking to learn or practice multi-threading, there are many other good ways to do it. Writing a multi-threaded search/sort would probably be good practice, and you wouldn't have to wrestle with unruly game code at the same time.
If you're looking to learn or practice multi-threading, there are many other good ways to do it. Writing a multi-threaded search/sort would probably be good practice, and you wouldn't have to wrestle with unruly game code at the same time.
Like everybody else said, you probably don't want multithreading at all. Unless your goal is to learn about multithreading.
In any case, I would advise against multiple threads in favor of multiple tasks.
The difference being that threads are pretty heavyweight and coarse-grained constructs that are slow to create, destroy and switch between. Also, when using threads, it will be hard to scale to make use of all available cores. Example, if you have two threads, one for rendering and one for logic, then the game will run slower on a single core processor than a single threaded game would and would only ever make use of two cores, even on processors with four or more cores available.
If, instead, you process with tasks, which are basically chunks of code which can be run in parallel (and are more fine-grained than threads - eg, your rendering code may consist of multiple tasks, your logic may consist of lots of tasks), then they would simply be executed sequentially on a single core machine (it would still have overhead, but less than with threads), half could run in one thread and the other half in a second thread on a dual core machine, four threads on a quad core machine etc etc.
Now, instead of thinking about parallel processing in terms of "what module do I run in another thread", you think of your code in terms of "what sub-parts of each module can be run at the same time" and then you split these into their own tasks. Take a look at the forum threads linked below for more details.
Finally, I wouldn't recommend that you write your own task system - this is very difficult to do well - instead use an existing task-based library. My favorite is Intel Threading Building Blocks (if you use C++).
Some recent gamedev.net threads for you to read:
In any case, I would advise against multiple threads in favor of multiple tasks.
The difference being that threads are pretty heavyweight and coarse-grained constructs that are slow to create, destroy and switch between. Also, when using threads, it will be hard to scale to make use of all available cores. Example, if you have two threads, one for rendering and one for logic, then the game will run slower on a single core processor than a single threaded game would and would only ever make use of two cores, even on processors with four or more cores available.
If, instead, you process with tasks, which are basically chunks of code which can be run in parallel (and are more fine-grained than threads - eg, your rendering code may consist of multiple tasks, your logic may consist of lots of tasks), then they would simply be executed sequentially on a single core machine (it would still have overhead, but less than with threads), half could run in one thread and the other half in a second thread on a dual core machine, four threads on a quad core machine etc etc.
Now, instead of thinking about parallel processing in terms of "what module do I run in another thread", you think of your code in terms of "what sub-parts of each module can be run at the same time" and then you split these into their own tasks. Take a look at the forum threads linked below for more details.
Finally, I wouldn't recommend that you write your own task system - this is very difficult to do well - instead use an existing task-based library. My favorite is Intel Threading Building Blocks (if you use C++).
Some recent gamedev.net threads for you to read:
How about something simple as OpenMP?
Its complexity is at a minimum, don't get the full juice you would from doing it the hard way, yet get a lot for the little amount of effort put into it.
Its complexity is at a minimum, don't get the full juice you would from doing it the hard way, yet get a lot for the little amount of effort put into it.
If you want something code free of licensing, you can check out my little threading implementation at http://nolimitsdesigns.com/game-design/threading-library/
It is only two files, requires no lib builds, free for any use and it is simple.
It is only two files, requires no lib builds, free for any use and it is simple.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
