Re: [Dev-C++] Multi threading in game

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!