Hi All.
I was wondering as to what would be the best way to simulate slowdowns in the game loop.
like what would happen if the game was run on a slower PC, would it still be playable.
i would like it to be able to 'throttle' down the speed like to n% of PC total.
i thought of the sleep function, but not sure that it was the *best* way to do it.
any suggestions ?
Thanks in advance.
1
Simulating slowdowns
Started by ryan20fun, Jun 21 2012 01:57 AM
3 replies to this topic
#1 Members - Reputation: 346
Posted 21 June 2012 - 01:57 AM
Never say Never, Because Never comes too soon. - ryan20fun
Disclaimer: Each post of mine is intended as an attempt of helping and/or bringing some meaningfull insight to the topic at hand. Due to my nature, my good intentions will not always be plainly visible. I apologise in advance and assure you I mean no harm and do not intend to insult anyone.
Disclaimer: Each post of mine is intended as an attempt of helping and/or bringing some meaningfull insight to the topic at hand. Due to my nature, my good intentions will not always be plainly visible. I apologise in advance and assure you I mean no harm and do not intend to insult anyone.
Sponsor:
#2 Members - Reputation: 333
Posted 21 June 2012 - 02:13 AM
Sleep() may do the trick... it won't allow for a fine range of tuning but will give you a general idea of how things are going...
If you have a high performance timer (ie something using QueryPerformanceCounter) then you can sit in a loop checking the time each iteration until you hit your desired limit - I use this in my engine to implement a frame rate cap, so at the end of the game loop it will sit in a while loop until the total frame time has hit the frame cap: ~16.66ms for 60 FPS, 20ms for 50 FPS, etc etc (1000/fps will give you the miliseconds).
In most cases, however, your game loop should be designed to be framerate and speed independent... this may give you some ideas: http://gafferongames.com/game-physics/fix-your-timestep/
Finally, just a little note... although I recommended Sleep above for testing, you should avoid using Sleep in production code completely... it's not very reliable and the OS may start doing things in the background (context switching to another thread/process which may eat up a lot of time).
Hope this makes some sense!
If you have a high performance timer (ie something using QueryPerformanceCounter) then you can sit in a loop checking the time each iteration until you hit your desired limit - I use this in my engine to implement a frame rate cap, so at the end of the game loop it will sit in a while loop until the total frame time has hit the frame cap: ~16.66ms for 60 FPS, 20ms for 50 FPS, etc etc (1000/fps will give you the miliseconds).
In most cases, however, your game loop should be designed to be framerate and speed independent... this may give you some ideas: http://gafferongames.com/game-physics/fix-your-timestep/
Finally, just a little note... although I recommended Sleep above for testing, you should avoid using Sleep in production code completely... it's not very reliable and the OS may start doing things in the background (context switching to another thread/process which may eat up a lot of time).
Hope this makes some sense!
#3 Members - Reputation: 2047
Posted 21 June 2012 - 03:59 AM
I would strongly advise against using sleep functions. It is better to have simulation and/or gameplay independent of render speed and render just as fast as it will go. Vertical sync will take care of throttling down things (if it's enabled). This will look good both on slow and fast machines!
If you really need to delay, use a timer and wait on it. The reason is that sleep functions are very unreliable, and while the granularity is acceptable on some operating systems (e.g. Linux), it is very bad on some systems (e.g. Windows). Sleep is usually specified in terms such as "delays for at least so-and-so-long and eventually returns, uh... when it does". This is absolutely not what you want in a game with animations. Say you're delayed for 16ms on a "normal" PC, then congrats, your FPS just dropped from 60 to 30. Say you're delayed for 80-90ms, your customer will start shouting, and if it happens regularly they'll call your support line.
Blocking on an event/timer/whatever has a much better accuracy and reliability, especially on operating systems with extremely poor sleep behaviour (read as: Windows). When a thread that is blocked on an event (or waitable timer, completion port, whatever) becomes ready, Windows will a) temporarily give it a higher scheduling priority and b) interrupt a running thread of lower priority in the middle of its time slice to allow the woken thread to run. This is exactly what you want.
On the other hand, when Sleep returns, it really does nothing special. The thread is ready to run, but that's all. This means it will eventually get a time slice when the round-robin scheduling comes to it. Or it won't, for indefinite time, as long as some higher priority thread is still running.
If you really need to delay, use a timer and wait on it. The reason is that sleep functions are very unreliable, and while the granularity is acceptable on some operating systems (e.g. Linux), it is very bad on some systems (e.g. Windows). Sleep is usually specified in terms such as "delays for at least so-and-so-long and eventually returns, uh... when it does". This is absolutely not what you want in a game with animations. Say you're delayed for 16ms on a "normal" PC, then congrats, your FPS just dropped from 60 to 30. Say you're delayed for 80-90ms, your customer will start shouting, and if it happens regularly they'll call your support line.
Blocking on an event/timer/whatever has a much better accuracy and reliability, especially on operating systems with extremely poor sleep behaviour (read as: Windows). When a thread that is blocked on an event (or waitable timer, completion port, whatever) becomes ready, Windows will a) temporarily give it a higher scheduling priority and b) interrupt a running thread of lower priority in the middle of its time slice to allow the woken thread to run. This is exactly what you want.
On the other hand, when Sleep returns, it really does nothing special. The thread is ready to run, but that's all. This means it will eventually get a time slice when the round-robin scheduling comes to it. Or it won't, for indefinite time, as long as some higher priority thread is still running.
Edited by samoth, 21 June 2012 - 04:01 AM.
#4 Members - Reputation: 580
Posted 21 June 2012 - 08:29 AM
You could use a program such as this to throttle your cpu. It won't be too useful for realistic measurements, however, since it only slows down the cpu. Besides a slower cpu, older hardware will have slower disks, slower ram, slower nb, slower graphics card, different cpu capabilities, etc....
