How freely do you use multithreading in your games?
Author
I'm a little curious how much or how little people here typically use threads when making their games. I think almost everyone puts their audio code in seperate threads (correct me if I'm wrong), but what about other pieces of game logic? I was thinking this morning about what happens when a new map loads in my game, and the answer is a lot. There are several calls to memory, some objects are constructed dynamically, etc. and if I tried to do all that computation inbetween two frames, there's an obvious lag in between. So to 'hide' that slow down, there are obvious tricks like fading out/in the old and new frames, and I thought maybe it would be a good idea to offload that computational work to a thread or something during that phase. I've done my fair share of multithreaded programming before, but never in a game. So I'm just curious to hear everyone's experiences with threads and game programming. [smile]
I know next to nothing about threads [except how difficult the bugs they tend to produce!]. I've only tried once, with your aforementioned audio thread. It actually worked kinda well.
Still, my [exceptionally limited] experiences are that if something can be done without threading, it's usually better not to use them. They're on my list of stuff to learn better, but not at any priority.
Still, my [exceptionally limited] experiences are that if something can be done without threading, it's usually better not to use them. They're on my list of stuff to learn better, but not at any priority.
If you can set the data structures (and allocators) up right, offloading resource-loading code is great, especially for streaming.
For my next project (which will have streaming), I'm thinking of doing one for audio, a few for physics (since NovodeX runs in seperate threads, IIRC), one to manage resource streaming, and then the main one which ties everything together and sends polys to the GPU. The GPU kind of counts as a seperate processor/thread, but not in the conventional sense :).
I've only done a bit of threaded code, so I'm sure the race conditions are going to be fun.
For my next project (which will have streaming), I'm thinking of doing one for audio, a few for physics (since NovodeX runs in seperate threads, IIRC), one to manage resource streaming, and then the main one which ties everything together and sends polys to the GPU. The GPU kind of counts as a seperate processor/thread, but not in the conventional sense :).
I've only done a bit of threaded code, so I'm sure the race conditions are going to be fun.
If you run similar tasks in diffrent threads, there are no performance benefit, unless you have multiprocessor or multi-core system. I would only prefer to seperate such things like networking or IO into different threads, because they generates small cpu overhead, but takes a lot of time.
I use one thread for the physics and one for the graphics in my engine at http://www.coolgroups.com/amaze/amazesetup5.exe.
Mike C.
http://www.coolgroups.com/
Mike C.
http://www.coolgroups.com/
all multithreading i have made was in networking and yet it produces lots and lots of problems. for example a message to delete a certain object from the client database. You cannopt dleete it directly because the client might be in the process of using the same object thus making the game crash. so you have to set a certain object state to deletion so the client will check the flag , iuf it is true it will delete the sepecifed object.
This is a small example of how multithreading can complicate life.
yet it has several usage and without it i couldn't have completed my game .
This is a small example of how multithreading can complicate life.
yet it has several usage and without it i couldn't have completed my game .
I started a game and used multithreading for the first time.
I made two threads:
1) all the windows stuff like: msg processing, drawing a buffer to the screen with some refresh rate, and because that is the main thread he also creates the second thread.
2) All the game logics, maths, input from user. the advantage in this is that I can write a continues code while the first thread must be a loop.
Because I don't use sound yet I didn't make a 3rd thread yet but i think that audio, windows messages and outputs, game logics and input, networking, and each subsystem inside the game that shouldn't depend on the others, should be seperated into diferrent threads.
I made two threads:
1) all the windows stuff like: msg processing, drawing a buffer to the screen with some refresh rate, and because that is the main thread he also creates the second thread.
2) All the game logics, maths, input from user. the advantage in this is that I can write a continues code while the first thread must be a loop.
Because I don't use sound yet I didn't make a 3rd thread yet but i think that audio, windows messages and outputs, game logics and input, networking, and each subsystem inside the game that shouldn't depend on the others, should be seperated into diferrent threads.
I have quite a few friends with dual-processor Macs, so I have leaned pretty heavily toward multi-threading in my projects.
As an example my current project is an infinite-LOD planet renderer, and the tiles are loaded on the fly by a separate thread.
I would probably use even more threads, but I use SDL, which requires all input and video calls be made from the same thread, and also I haven't come up with a decent approach to make threads play nicely with my kernel/task system.
As an example my current project is an infinite-LOD planet renderer, and the tiles are loaded on the fly by a separate thread.
I would probably use even more threads, but I use SDL, which requires all input and video calls be made from the same thread, and also I haven't come up with a decent approach to make threads play nicely with my kernel/task system.
I use them when I must, or when the benefits are large enough.
For example, to enable non-blocking handling of blocking IO-calls or to feed polled status data into a message/event queue.
The basic rule is to never use threads unless you have to. The problems of proper synchronization, exception handling and sequencing often outweighs the benefits of multiple threads. Heavy thread synchronization also have a tendency to reduce performance compared to a non-threaded solution.
For example, to enable non-blocking handling of blocking IO-calls or to feed polled status data into a message/event queue.
The basic rule is to never use threads unless you have to. The problems of proper synchronization, exception handling and sequencing often outweighs the benefits of multiple threads. Heavy thread synchronization also have a tendency to reduce performance compared to a non-threaded solution.
I never use them unless there's no other effective way to do it. My most recent game is multiplayer, and has a couple threads to sit on (blocking) network sockets and read from them into a queue. That queue is the only way the thread touches any other part of the program.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
