Thread: [Dev-C++] Multi threading in game
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
dev-cpp-users
|
From: Philip B. <phi...@pb...> - 2007-11-13 01:16:22
|
Hello everyone, This will be a rather long message. I have a question regarding multi threading and syncrhonization for a = game that I'm working on. The game will have hundreds of objects = (enemies, bullets and so on), and I am trying to think of an efficient = way to implement this using multiple threads. I will have input and player actions in one thread since they are tied = together, window message processing in the main thread which will be = idle for the most part, and then a thread which handles the enemies. I = will give them different priority levels so that they don't all move at = full speed all the time. I have two ideas for how to do this: 1. Give each enemy its own critical section object so that it is free = whenever it is not being read or written to. Then whenever the player = thread or another enemy in the same thread wants to access it either for = reading or writing, it'll enter the critical section. I figure that this = could potencially cause delays, for example what if an enemy decides to = move while the player is firing at it and thus modifying its data from a = different thread? 2. Have a critical section for all the enemies, which I guess would not = be very practical but it is one idea that I had. Can anyone perhaps suggest a good way of handling this? I want to be = able to read and write the enemy information from any thread as fast as = possible, though most of the work will occur in one and the same thread = (the enemy thread). Thanks in advance for any help. Regards Philip Bennefall |
|
From: Chris M. <lor...@gm...> - 2007-11-13 01:35:33
|
On Nov 12, 2007 5:15 PM, Philip Bennefall <phi...@pb...> wrote: > Hello everyone, > > This will be a rather long message. My resolution is 1680x1050 and it didn't even take up the whole screen :) > I have a question regarding multi threading and syncrhonization for a game > that I'm working on. The game will have hundreds of objects (enemies, > bullets and so on), and I am trying to think of an efficient way to > implement this using multiple threads. You're using pthreads, obviously. > I will have input and player actions in one thread since they are tied > together, window message processing in the main thread which will be idle > for the most part, and then a thread which handles the enemies. I will give > them different priority levels so that they don't all move at full speed all > the time. I have two ideas for how to do this: Wrong. You're looking at it from where the chair, which isn't how to write an application. What you want to do is consider which parts of the game will induce latencies. Primarily, the networking, caching, and graphics components. You're going to spend time waiting for network packets, time waiting for files from the hard drive, and for things to render. It's best to encapsulate these into their own threads so that they can do their thing with a certain degree of asynchronousness from the primary game loop. Enemies and allies are the same to the game engine. Whether one is controlled by AI simulations and one by the chimpanzee between the chair and keyboard makes little difference if you do it correctly and make sure they use the same input paths to the core game engine. > 1. Give each enemy its own critical section object so that it is free > whenever it is not being read or written to. Then whenever the player thread > or another enemy in the same thread wants to access it either for reading or > writing, it'll enter the critical section. I figure that this could > potencially cause delays, for example what if an enemy decides to move while > the player is firing at it and thus modifying its data from a different > thread? Read about pthred mutexes. > 2. Have a critical section for all the enemies, which I guess would not be > very practical but it is one idea that I had. You're thinking, but it won't work :( > Can anyone perhaps suggest a good way of handling this? I want to be able to > read and write the enemy information from any thread as fast as possible, > though most of the work will occur in one and the same thread (the enemy > thread). Speed is achieved when you ditch silly things like XML and strings to throw around core game data. Threading is used to make high latency components asynchronous from the rest of the game to make the framerate less laggy. -- Registered Linux Addict #431495 http://profile.xfire.com/mrstalinman John 3:16! |
|
From: Per W. <pw...@ia...> - 2007-11-13 02:08:05
|
My guess is that the code you perform in an enemy is very quick (probably microseconds) so waiting for a lock shouldn't be a problem. Having one big critical section is more important if you have a _huge_ amount of objects and have to think about consumed resources. If you can, it is better to have a granular solution, where you lock small sections. 1) It gives less chance of a collision. 2) It will probably be locked for a shorter time - you don't get tempted to take a lock and then iterate through all objects and perform mass-updates. There might even be situations where it might be meaningful to have more than one lock/object. Some actions may for example only affect (or be accted by) a limited set of object properties, while other actions may affect (or be affected by) a different set of properties. A separate issue: Do all objects make their decisions based on the "current" state, or do you make a snapshot of all state and base the next action on the snapshot state? If everything is real-time, then it is reasonable to walk through all objects continuously in a round-robin. If the game is turn-based (or pseudo-realtime) then all objects decides what will happen based on a locked state and then all objects switches to the new state before making new decisions. In this case, you need hardly any locking at all. Only one thread is responsible for updating each object, and the input state is fixed until all book-keeping has been done. Then all threads can decide to lock their huge locks, switch to next state and then release the locks and start deciding on next state. About total CPU load: Need all enemies be awake? Many games can sleep all enemies more than a specific distance from a player. What you can't see, you can't complain about, if you excuse the pun :) /pwm On Tue, 13 Nov 2007, Philip Bennefall wrote: > Hello everyone, > > This will be a rather long message. > > I have a question regarding multi threading and syncrhonization for a > game that I'm working on. The game will have hundreds of objects > (enemies, bullets and so on), and I am trying to think of an efficient > way to implement this using multiple threads. > > I will have input and player actions in one thread since they are tied > together, window message processing in the main thread which will be > idle for the most part, and then a thread which handles the enemies. I > will give them different priority levels so that they don't all move at > full speed all the time. I have two ideas for how to do this: > > 1. Give each enemy its own critical section object so that it is free > whenever it is not being read or written to. Then whenever the player > thread or another enemy in the same thread wants to access it either for > reading or writing, it'll enter the critical section. I figure that this > could potencially cause delays, for example what if an enemy decides to > move while the player is firing at it and thus modifying its data from a > different thread? > > 2. Have a critical section for all the enemies, which I guess would > not be very practical but it is one idea that I had. > > Can anyone perhaps suggest a good way of handling this? I want to be > able to read and write the enemy information from any thread as fast as > possible, though most of the work will occur in one and the same thread > (the enemy thread). > > Thanks in advance for any help. > > Regards > Philip Bennefall |
|
From: Philip B. <phi...@pb...> - 2007-11-13 10:47:48
|
Hi Per, Thanks for all the help. You gave some great information, as always. The game is realtime, meaning that more than one thread will have to modify the enemy at the same time (the data cannot be cashed). The player thread will look for the enemies when the player walks for instance which means reading, or when he fires to see if an enemy was hit which means writing if the enemy needs to be woonded. So you think it's safe to have a critical section for each enemy? That's the way I originally planned it but I thought that maybe entering and leaving all these critical sections constantly would take up too much processor power. It's a good idea having several critical sections for each character depending on the action performed, but in this case it's not really an option because all it really does is to read and modify members in a struct. Regards Philip Bennefall ----- Original Message ----- From: "Per Westermark" <pw...@ia...> To: "Philip Bennefall" <phi...@pb...> Cc: <dev...@li...> Sent: Tuesday, November 13, 2007 3:07 AM Subject: Re: [Dev-C++] Multi threading in game > My guess is that the code you perform in an enemy is very quick (probably > microseconds) so waiting for a lock shouldn't be a problem. > > Having one big critical section is more important if you have a _huge_ > amount of objects and have to think about consumed resources. If you can, > it is better to have a granular solution, where you lock small sections. > 1) It gives less chance of a collision. > 2) It will probably be locked for a shorter time - you don't get tempted > to take a lock and then iterate through all objects and perform > mass-updates. > > There might even be situations where it might be meaningful to have more > than one lock/object. Some actions may for example only affect (or be > accted by) a limited set of object properties, while other actions may > affect (or be affected by) a different set of properties. > > A separate issue: Do all objects make their decisions based on the > "current" state, or do you make a snapshot of all state and base the next > action on the snapshot state? If everything is real-time, then it is > reasonable to walk through all objects continuously in a round-robin. If > the game is turn-based (or pseudo-realtime) then all objects decides what > will happen based on a locked state and then all objects switches to the > new state before making new decisions. In this case, you need hardly any > locking at all. Only one thread is responsible for updating each object, > and the input state is fixed until all book-keeping has been done. Then > all threads can decide to lock their huge locks, switch to next state and > then release the locks and start deciding on next state. > > About total CPU load: Need all enemies be awake? Many games can sleep all > enemies more than a specific distance from a player. What you can't see, > you can't complain about, if you excuse the pun :) > > /pwm > > On Tue, 13 Nov 2007, Philip Bennefall wrote: > >> Hello everyone, >> >> This will be a rather long message. >> >> I have a question regarding multi threading and syncrhonization for a >> game that I'm working on. The game will have hundreds of objects >> (enemies, bullets and so on), and I am trying to think of an efficient >> way to implement this using multiple threads. >> >> I will have input and player actions in one thread since they are tied >> together, window message processing in the main thread which will be >> idle for the most part, and then a thread which handles the enemies. I >> will give them different priority levels so that they don't all move at >> full speed all the time. I have two ideas for how to do this: >> >> 1. Give each enemy its own critical section object so that it is free >> whenever it is not being read or written to. Then whenever the player >> thread or another enemy in the same thread wants to access it either for >> reading or writing, it'll enter the critical section. I figure that this >> could potencially cause delays, for example what if an enemy decides to >> move while the player is firing at it and thus modifying its data from a >> different thread? >> >> 2. Have a critical section for all the enemies, which I guess would >> not be very practical but it is one idea that I had. >> >> Can anyone perhaps suggest a good way of handling this? I want to be >> able to read and write the enemy information from any thread as fast as >> possible, though most of the work will occur in one and the same thread >> (the enemy thread). >> >> Thanks in advance for any help. >> >> Regards >> Philip Bennefall > > |
