Multithreaded games

[Pu-239]

So I'm programming this game and I'm using multiple threads (event thread which waits for user input, sets a flag which is read by an update thread looping every X # of milliseconds, which updates objects drawn by a draw thread on an untimed loop going as fast as it can (which is stupid, since there's no point to refreshing something faster than it is updated except for bragging about FPS). Anyway, do I really need to lock the data structures, since each one only has one thread writing to it and another thread reading from it, and any errors will get fixed in the next frame (if I need to lock it, that means that if the drawing thread is slow while reading/processing a data structure, the updated thread must keep waiting until the lock is released)?

An advantage to splitting the threads this way is that the drawing thread can be suspended and the game state still updating, but I don't know if performance loss vs flexibility is a worthy tradeoff. Another reason is SMP/SMT/HT systems.

Finally, should I just merge the update/draw thread and have the draw thread call update functions every [time since start] modulus 33ms (for 30FPS)? Also, should I lock the maximum FPS at 30? And why don't most games lock down the maximum FPS this way, since there doesn't seem to be any advantage to going at 100+?

Note: I want confirmation- in case anyone complains that I may have answered my own question.

[Praxis]

Dunno this since I'm not a programmer, but I remember something about one of the Unreal games (the mac edition, at least) and SMP. Someone was telling me that Unreal would have the game itself running on one processor/thread, and would offload the sound processing and extra bits like that to the second processor.

Perhaps something like that might be a good idea?
Or perhaps I completely don't understand the question

[Antares]

if structures are defentily only used by a single thread then locking them with, of instance mutex, is of course pointless. but since threads often need some communication, it's a good idea to prepare it at least.

and for the refreshing thing. i dont know what system routines are involved in this, but have you thought about software interrupts or searched for possible available call-back functions?

[phongn]

Dunno this since I'm not a programmer, but I remember something about one of the Unreal games (the mac edition, at least) and SMP. Someone was telling me that Unreal would have the game itself running on one processor/thread, and would offload the sound processing and extra bits like that to the second processor.

UT on the Mac (can't remember which edition, but only one of them) used SMP to offload sound processing. Multithreaded games remain rare, especially due to the difficulty of writing such programs, the limited audience and the fact that not all problems lend themselves to be parallized.

Perhaps something like that might be a good idea?
Or perhaps I completely don't understand the question

You don't

[Praxis]

You don't

Okay. *runs off and hides*

[Xon]

When doing thread synchronization, always keep the amount of data locked at anytime to a minium.

The input thread should chuck the input events into a thread safe queue(converting the OS input data into a format your game can us), and some other thread actually processes it(input causing actual actions to occur). This is a common technique for high preformance and smooth input.

Also make sure you have a fixed timestep, and not a floating one. As the fixed timestep prevents floatpoint rounding issues which change due to the framerate. Do not couple your internal update rate(must be predictable) with the framerate(is variable).

An example of a fixed step framerate(C#/pseudo-code):

Code: Select all

// framerate step in milliseconds
public const int framestep = 30;
public void update()
{
int64 UpdateStartTime = HighPresisionCounter;
// do graphics updates & input processing
...
// do the internal updates
int64 GameStateUpdateTime = HighPresisionCounter - UpdateStartTime;
while (GameStateUpdateTime > framestep)
{
DoGameStateUpdates( framestep );
GameStateUpdateTime -= framestep;
}
}

An example of a floating step framerate(C#/pseudo-code):

Code: Select all

public void update()
{
int64 UpdateStartTime = HighPresisionCounter;
// do graphics updates & input processing
...
// do the internal updates
int64 GameStateUpdateTime = HighPresisionCounter - UpdateStartTime;
DoGameStateUpdates( GameStateUpdateTime );
}

The reason fixed step updates is a good idea is decouples the internal game state update rate from the graphical framerate.

Note: the sample code has never been touched by a compiler, and requires a bunch more logic, thats only the basic structure of the ideas I'm trying to illustrate.