How many threads for a game?
Hi all,
I am fairly new at developing games (for fun), but not at programming.
I am attempting to make a simple demo in C# for a game I may (or may never) code in DirectX one day. For now, I am only using GDI+ to toy around with functionalities such as timing, objects managment, etc.
My question is : how many threads a game really needs? I mean by that, that if a game has a single thread, used to generate game objects and to animate the scene as well, what will happen if there is a big lag? My guess is that not only the graphics will lag, but also the object creation engine, which may skip a few objects (enemies, gun shots, etc.) to create (probably resulting in an easier gameplay as not all objects that should be there aren't?).
So is there a need to have 2 threads? One for object creation, which should be as fast and accurate as possible, and another one for animation, whose running speed depends on the framerate wanted?
Thanks for helping me!
ibiza
Lagging won't cause objects to not be created, just for them to be created in a longer space of time. The frames per second will decrease, but those frames will be the same.
You shouldn't need to use any threading at all. It is only important to people creating next generation games and technology that will take advantage of multi core CPUs. It can also be used to simpilfy code in some cases, but generally you should avoid threading and all the headaches that come with it unless you need to. C# is not a good language for concurrent programming.
You shouldn't need to use any threading at all. It is only important to people creating next generation games and technology that will take advantage of multi core CPUs. It can also be used to simpilfy code in some cases, but generally you should avoid threading and all the headaches that come with it unless you need to. C# is not a good language for concurrent programming.
Hi, thanks for your reply!
Well, a program is a thread, that's what I meant with a single thread...no thread at all if you prefer.
But in my case, I have a simple program where I can adjust the refresh rate of my main loop (which handles both the object creation AND the animation), with the help of a slider. I have a "Shot generator" whichs generates simple circles for now, each one with the same constant speed and direction The interval at which these circles are generated is also constant : one every 100ms (or 10 / second). What happens when I decrease the frame rate to less than 10fps (let's say 5), is that there are no more 10 circles per second generated, but rather 5. And it's normal, sinces the loop is only executed every 200ms when the framerate is at 5.
So what would be the solution in my case to still generate 10 circles per second, but update their position only at every 200ms?
This is the problem I am actually facing...
thanks! :)
Well, a program is a thread, that's what I meant with a single thread...no thread at all if you prefer.
But in my case, I have a simple program where I can adjust the refresh rate of my main loop (which handles both the object creation AND the animation), with the help of a slider. I have a "Shot generator" whichs generates simple circles for now, each one with the same constant speed and direction The interval at which these circles are generated is also constant : one every 100ms (or 10 / second). What happens when I decrease the frame rate to less than 10fps (let's say 5), is that there are no more 10 circles per second generated, but rather 5. And it's normal, sinces the loop is only executed every 200ms when the framerate is at 5.
So what would be the solution in my case to still generate 10 circles per second, but update their position only at every 200ms?
This is the problem I am actually facing...
thanks! :)
Well multithreading could be useful in this situation. Lots of beginners think they need seperate threads for everything, so thats why I suggested not to bother.
If your frame rate drops to 5 FPS then you have big problems anyway, and if it high enough you should be able to use timing code in your main loop to decide when to perform certain actions.
If you can do it in a reasonable way without threading, do it, but you don't have to rule threading out either.
If you do use multiple threads, you have to be very careful about shared state (variables accessed by both threads). Try to keep shared state to a minimum, and be very careful to lock access to variables you do share between threads.
You are in a better position than C++ programmers, but C# still has poor support for concurrency. It does have the lock construct though, and probably higher level constructs in the .NET libraries (I'm not a .NET expert at all).
If your frame rate drops to 5 FPS then you have big problems anyway, and if it high enough you should be able to use timing code in your main loop to decide when to perform certain actions.
If you can do it in a reasonable way without threading, do it, but you don't have to rule threading out either.
If you do use multiple threads, you have to be very careful about shared state (variables accessed by both threads). Try to keep shared state to a minimum, and be very careful to lock access to variables you do share between threads.
You are in a better position than C++ programmers, but C# still has poor support for concurrency. It does have the lock construct though, and probably higher level constructs in the .NET libraries (I'm not a .NET expert at all).
Thank you very much.
What do you mean by "using timing code in your main loop to decide when to perform certain actions"?
In fact, I was wondering how professionally-made games were handling the issue I am facing? A game can for sure drop to low-levels FPS like 5/second, even for only a fraction of second, and object creation is still not altered.
Of course, I'd prefer to use a single thread for object creation and animation, but is there a way to correct my problem without splitting animation and object creation in two distinct threads? If so, I'd like to hear it, before trying to do a multi-threading game...it would be sure much simpler.
What do you mean by "using timing code in your main loop to decide when to perform certain actions"?
In fact, I was wondering how professionally-made games were handling the issue I am facing? A game can for sure drop to low-levels FPS like 5/second, even for only a fraction of second, and object creation is still not altered.
Of course, I'd prefer to use a single thread for object creation and animation, but is there a way to correct my problem without splitting animation and object creation in two distinct threads? If so, I'd like to hear it, before trying to do a multi-threading game...it would be sure much simpler.
Well your main loop executes once per frame, so if you want to do something based on time rather than frames you have to calculate how much time has passed. In your main loop you would do all your normal work for this frame, test if 100ms has passed since you last created a circle, and if it has, create one.
If you used a seperate thread, you'd still have to use this time checking code, but the circle creation would not lag while the rendering thread slowed down. But still, if you can't see the circles that are being created, does it really matter anyway?
If you used a seperate thread, you'd still have to use this time checking code, but the circle creation would not lag while the rendering thread slowed down. But still, if you can't see the circles that are being created, does it really matter anyway?
Ok, thanks a lot for your help.
But if I develop a game where timing is vital (I don't know if you know "Ikaruga" :P ), does the discussion we just had means that the game probably has a distinct thread for animation and another one for object handling?
I mean, a game like that cannot afford to "presume" that the FPS will always be the same, and top notch.
In other words, if I want to be 100% sure that every time I run the game, whatever the FPS may be during the gameplay, if I want my objects/ennemies always created *exactly* at the same timing, every time, I do not have choice to have two threads? Because with only one, any lag causes a delay, as minimal as it may be, and affets the timing of the game...
Am I correct?
But if I develop a game where timing is vital (I don't know if you know "Ikaruga" :P ), does the discussion we just had means that the game probably has a distinct thread for animation and another one for object handling?
I mean, a game like that cannot afford to "presume" that the FPS will always be the same, and top notch.
In other words, if I want to be 100% sure that every time I run the game, whatever the FPS may be during the gameplay, if I want my objects/ennemies always created *exactly* at the same timing, every time, I do not have choice to have two threads? Because with only one, any lag causes a delay, as minimal as it may be, and affets the timing of the game...
Am I correct?
What makes you think timing won't be an issue with multiple threads?
Threads can be blocked, and they may be executed more or less frequently than you expect.
I really don't see your point about "skipping" object creation. If you use a single thread, then everything will happen sequentially. If you want to create 25 objects, they're created before anything else happens. It sounds more like something I'd expect to happen in a (clumsily implemented) multithreading scenario.
If you want to ensure that everything is done at some specific time, look into fixed timesteps. The idea is to run the game logic in fixed intervals, independent of framerate. That's more or less the only way to ensure that everything happens at the speed you want. And no threading is required.
Threads can be blocked, and they may be executed more or less frequently than you expect.
I really don't see your point about "skipping" object creation. If you use a single thread, then everything will happen sequentially. If you want to create 25 objects, they're created before anything else happens. It sounds more like something I'd expect to happen in a (clumsily implemented) multithreading scenario.
If you want to ensure that everything is done at some specific time, look into fixed timesteps. The idea is to run the game logic in fixed intervals, independent of framerate. That's more or less the only way to ensure that everything happens at the speed you want. And no threading is required.
Yes, I know Ikaruga [grin]. A game like that is going to have a lot of slowdown, obviously. I'm not sure how the game was coded, Treasure have a reputation for using all sorts techniques.
Spoonbender is right. His comment about everything happening sequentially is what I was trying to get at earlier. Everything that happens in a frame will still happen, just slower.
Splitting the object creation off into another thread isn't going to solve anything. If the rendering thread slows to a crawl, it won't matter that objects are still being created, in fact it will make the situation worse. You won't be able to see the enemies that are spawning anyway, because they arn't being drawn, they are just taking up more resources that you are already low on.
Spoonbender is right. His comment about everything happening sequentially is what I was trying to get at earlier. Everything that happens in a frame will still happen, just slower.
Splitting the object creation off into another thread isn't going to solve anything. If the rendering thread slows to a crawl, it won't matter that objects are still being created, in fact it will make the situation worse. You won't be able to see the enemies that are spawning anyway, because they arn't being drawn, they are just taking up more resources that you are already low on.
Take a look at this code. It shows how to lock a game at a specific rate regardless of the frame rate:
int const SIMULATION_INTERVAL = 100; // 10 updates per second while( !game_over ) { static int last_time = get_time(); int current_time = get_time(); while ( current_time - last_time >= SIMULATION_INTERVAL ) { update_simulation(); last_time += SIMULATION_INTERVAL; } render(); }
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement