Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » rest(1) 65 fps!?

This thread is locked; no one can reply to it. rss feed Print
 1   2 
rest(1) 65 fps!?
Kitty Cat
Member #2,815
October 2002
avatar

Quote:

If you're not going to use rest(1) you must at least use rest(0), or else your game will not give any CPU time back to the system and background processes may stop working properly.

Not really, but it's the Right Thing to do. Under any multitasking OS you would need to worry about, the OS will make sure other processes get some processor time. Calling rest(0) just tells the OS "Hey, if anything's waiting for the CPU, let 'em have it, but give it back to me when they're done." instead of waiting for the OS to "forcefully" take the CPU back. Calling rest(1), on the other hand, tells the OS "I don't need the CPU right now. Do whatever you want with it but give it back to me ASAP after 1 millisecond."

And note that timer granularity may not be all that high. Even if you call rest(1), it's likely to be about 5 to 10 ms before it gets back to you. The actual time it takes is based on many small inconceiveable details, and is for all intents and purposes, random within a 10 ms range.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Albin Engström
Member #8,110
December 2006
avatar

HoHo said:

Why it isn't? You can't make meaningful decisions only based on FPS without looking at what the CPU does. In your and OICW's case it is probably idling most of the time and that is a good thing.

if it's not supposed to be that way it's wrong :/.. wrong wrong wrong!

HardTranceFan said:

nm

que?

Kris Asick said:

Time to clear up some things:

If you put rest(1) in your game loop, it will burn 1 ms of processor time per frame, giving it back to the CPU. Thus the absolute maximum framerate possible would be 1000 fps, assuming your loop did practically nothing besides rest(1). If you're getting a huge framerate drop by adding rest(1), then you're probably adding it in the wrong spot and it's being called more than once per frame. To know for certain if it's working properly you need to make an empty loop that calls rest(1) a certain number of times, then compare that with an Allegro timer to see if the two are running the same speed. If not, I'm willing to bet that Allegro programs aren't the only ones having timing problems on your system.

Also consider that framerate drops exponentially for the amount of processing you're doing. For instance, if your game logic uses 5 ms of processor time, you would have a framerate of 200 FPS. If it uses 10 ms, 100 FPS. 20 ms, 50 FPS. 40 ms, 25 FPS. As you'll see, it doesn't take much extra to kill the framerate.

If you're not going to use rest(1) you must at least use rest(0), or else your game will not give any CPU time back to the system and background processes may stop working properly. Using rest(1) over rest(0) isn't necessary, but increases I/O compatability in Allegro 4.1.0 or higher under older Windows OSes. (Which is why I use it.)

Be careful where you put the rest() commands. Do not put them immediately before a vsync() or triple buffering command, do not put them inside an acquire/release pair, do not put them in your timer routines and be certain they're only being called once per frame. (Leave rest() commands out of loops that may repeat more than once per frame.)

If you're still having doubts, set up your rest() commands to be called less often than the framerate. (For instance, call rest(1) every four frames or so.) This might still work as intended, but I've never tried it (yet) so I can't guarantee it will.

Lastly, about framerates: The Human brain can distinguish individual frames up to around 24 FPS. After that, the brain no longer sees each frame, but motion. That does not mean the brain can't figure out higher framerates, it just means that the brain stops being able to perceive each individual frame. The point at which framerates become indistinguishable varies with each person. For me, it's around the 100 FPS mark. Movies run at around 24 FPS. Thus if you're making a game using a real-time game engine, don't worry about the framerate being only 60-something: Not too many people will be able to tell and even fewer will care.

i'm pretty sure i'm not calling rest(x) more than one time per frame.. i have now changed the resolution from 640x480 to 320x240 due to
the cpu working it's ass of drawing fullscreen pictures.. thats not really the reason.. i just like really low resolution or very high resolution.. although i love 640x480, 320x240 is cooler - -, and the cpu doesn't even need to breath to draw..
-
thanks.

Kitty Cat said:

Even if you call rest(1), it's likely to be about 5 to 10 ms before it gets back to you

that's outrageous!

HoHo
Member #4,534
April 2004
avatar

Quote:

if it's not supposed to be that way it's wrong :/.. wrong wrong wrong!

Say what?

As I said before, stop worrying about performance. As long as it works fast enough to be bareable to develop on your machine it is good enough. Once the game is ready then start optimizing. Optimizing before that will be meaningless for two reasons:
1) There is a good chance you will replace the optimized piece of code with something else since it doesn't do what you want
2) you won't finish the game anyway and wasting time optimizing it will only slow your progress down

__________
In theory, there is no difference between theory and practice. But, in practice, there is - Jan L.A. van de Snepscheut
MMORPG's...Many Men Online Role Playing Girls - Radagar
"Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!" - Jakub Wasilewski

Albin Engström
Member #8,110
December 2006
avatar

that may be right.. i think i'm going to make something now, something small that is..

bamccaig
Member #7,536
July 2006
avatar

GullRaDriel said:

For those who have a car, we admit it can easily reach 180 km/h. Do you even drive a whole travel at this speed ? No. That the same with your FPS. Even if it can reach the light speed, it is not needed.

The speed that a car can travel is generally determined by the engine's output power. More power is required to climb a hill or pull a trailer, or even when there is more cargo or persons inside. In order to perform adequately when the car is put under it's maximum load there needs to be enough power (and torque) for it to satisfy these requirements. Conversely, when the car is at it's minimum load, it resultantly has extra power and torque that it doesn't need (though some of us will take advantage anyway). {must-fight-urge-to-smiley}

Some vehicles do have restriction mechanisms that either limit the RPMs, the top speed, or a combination of variables to prevent the car from actually reaching it's potential.

You don't cruise around at 100 MPH, but not because speed is bad: only because it would be unsafe in today's traffic model (some people can't drive safely doing 40 Km/h); humans simply can't react quickly enough to do stop and go driving from 0-180-0, stop-light to stop-light; and it would exhaust resources faster than necessary (and as a result cost a whole lot more). We don't need to get to the grocery store in 30 seconds. We can wait that 5 minutes: especially when compared to not making it at all.

As far as a game's FPS, you need to keep in mind that you're sharing resources with the system. It would be great if we could reliably achieve astronomical frame rates, but you also don't need 600 FPS to run smoothly. Still though, I would look into why there is such a major difference. Also how are you counting fps?

Tobias Dammers
Member #2,604
August 2002
avatar

You cannot physically get a higher FPS than what your monitor vsync is set to. Keep that in mind. So if your monitor is set to 85 Hz (a common setting), every frame above those 85 you render per second is a waste of cpu time (and energy) - you will never see it. It doesn't make your game any smoother; if you think it does, go see a brain surgeon or a shrink.
600 fps equals a frame render time of 1.6 ms, 64 fps is 15.6 ms. The same speed decrease (14 ms) applied AGAIN will result in ~33 fps - still playable, and also unlikely, since the rest() statement obviously adds 14 msecs of idling to your main loop. Really, you have nothing to worry about. I'd love to see the main loop though, I'm pretty sure the rest(1) is in an obscure place, or you're doing some very unorthodox frame buffering.

Oh, and on the car analogy:
1. I know some people who do cruise at 180 km/h for hours; in Germany, this is even legal.
2. The top speed of a car is determined by a number of factors, output power being only one of them. The faster you go, the more important aerodynamics become. Apart from that, car engines perform best in a quite small RPM window, so the gear layout also has crucial impact on the car's top speed - if the top gear can't keep the engine inside the window, then you can't accelerate easily, even if in theory you have the engine power.
3. Even with zero reaction time, today's engines cannot accelerate a car from 0 to 180 km/h between two traffic lights in typical urban conditions.
4. I walk to the grocery store.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Albin Engström
Member #8,110
December 2006
avatar

{
  while(momo>0)
  {
  momo--;
  "looped"-logic();
  }
  
  fps-rate-logic();
    
  graphics();
  rest(x);
}

the code does not look like this of course..

also... if this"You cannot physically get a higher FPS than what your monitor vsync is set to. Keep that in mind." was somewhat directed to me i just want to inform you that i'm well aware of that..

"since the rest() statement obviously adds 14 msecs of idling to your main loop" thats creepy... isn't there a better way to do "resting"?

Tobias Dammers
Member #2,604
August 2002
avatar

Quote:

the code does not look like this of course..

Then what does it look like?
Try to post an example of actual code that shows the behaviour you describe, and we'll see what it does and why.

Quote:

also... if this"You cannot physically get a higher FPS than what your monitor vsync is set to. Keep that in mind." was somewhat directed to me

Yes it was...

Quote:

i just want to inform you that i'm well aware of that..

Then why do you want 600 fps?

Quote:

"since the rest() statement obviously adds 14 msecs of idling to your main loop" thats creepy... isn't there a better way to do "resting"?

No, not really. You could use OS-specific thread management, but I suspect that it might interfere with what allegro does thread-wise, and it's definitely not cross-platform.
OTOH, if a single rest(1) statement causes the average frame time to rise by 14 ms, then something is wrong. Either with your computer, or with your code.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Kris Asick
Member #1,424
July 2001

Kitty Cat: You're right in one regard, multi-tasking operating systems will generally be fine without a rest() statement to give time back... not all computer hardware will be however. I have one story of a person who's computer would overheat when running an older version of PixelShips that didn't have rest() statements in it. I personally have had issues with some 3D programs (using another game library) that didn't include equivalent statements. There will always be the rogue hardware configuration that needs to be explicitly told that it can have some CPU time back for other processes and I really don't know why, just that it can happen.

The moral: Always give some CPU time up. Don't hog it.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Albin Engström
Member #8,110
December 2006
avatar

Tobias Dammers said:

Then what does it look like?

i think someone wanted to know how my main routine looked like?..

Tobias Dammers said:

Then why do you want 600 fps?

When did i say i wanted 600 fps!? - - i want at least as much as the monitor can display.

bamccaig
Member #7,536
July 2006
avatar

Tobias Dammers said:

I know some people who do cruise at 180 km/h for hours; in Germany, this is even legal.

The only place you could possibly "cruise" doing 180 Km/h for hours is on a large highway or freeway. The German autobahn, for example. That's not even really related to stop-and-go traffic, where it's not feasible. On top of that, the resources burned doing 180 Km/h for hours would be enough to notice compared to cruising at the "recommended" 130 Km/h.

If you enjoy driving and speed than you might enjoy the 180. I probably fit this model (in fact, if my car could do more I probably would at times). Others that are conservative would probably not want to burn the extra fuel. You know, like Europeans.

Don't bother bitching that you're European and speed or whatever... The majority of cars in Europe are small and lack high performance so you're automatically trapt in your continent's conservativeness! Besides, I'm only kidding. Germany makes cool cars. Italy makes semi-cool cars. It's the other countries that suck.

Tobias Dammers said:

The top speed of a car is determined by a number of factors, output power being only one of them. The faster you go, the more important aerodynamics become. Apart from that, car engines perform best in a quite small RPM window, so the gear layout also has crucial impact on the car's top speed - if the top gear can't keep the engine inside the window, then you can't accelerate easily, even if in theory you have the engine power.

Absolutely. There are other factors as well that limit top speed such as weather and road conditions, however, the engine's power output is where it all begins. The other factors are where the power is lost along the chain.

Also, acceleration is derived from torque, not power. If the engine remained at the same speed and the gear ratio remained the same (and all other variables remained constant) your speed and acceleration wouldn't change so there's no point leaving the engine in that window.

The real strategy is designing the engine and drive train to maximize power and torque curves, at the rear wheels (or the bitch front wheels or both), while the car is designed to be as aerodynamic as possible (without sacrificing style) to minimize loss.

Tobias Dammers said:

Even with zero reaction time, today's engines cannot accelerate a car from 0 to 180 km/h between two traffic lights in typical urban conditions.

There aren't ANY urban conditions where my car can get from 0-180-0 between stoplights. In fact, my car tops out at 175.

bamccaig said:

...because it would be unsafe in today's traffic model (some people can't drive safely doing 40 Km/h); humans simply can't react quickly enough to do stop and go driving from 0-180-0, stop-light to stop-light; and it would exhaust resources faster than necessary (and as a result cost a whole lot more).

Perhaps you missed that part?

Even if it was feasible for cars to do 0-180-0 from stop-light to stop-light, the human brain couldn't process it fast enough so there's no point developing the technology - at least not until computers drive.

Albin Engström said:

When did i say i wanted 600 fps!? - - i want at least as much as the monitor can display.

Technically, I don't think you did, however, you did ask if 65 was too little. I think Tobias was just making it clear that 600 is tooooooo much.

HardTranceFan
Member #7,317
June 2006
avatar

Quote:

I said:

nm

que?

nm = never mind. I wrote something, and later decided it was irrelevant and so I removed the contents of my post.

--
"Shame your mind don't shine like your possessions do" - Faithless (I want more part 1)

Tobias Dammers
Member #2,604
August 2002
avatar

Quote:

i think someone wanted to know how my main routine looked like?..

I meant something that actually compiles.

Quote:

If you enjoy driving and speed than you might enjoy the 180. I probably fit this model (in fact, if my car could do more I probably would at times). Others that are conservative would probably not want to burn the extra fuel. You know, like Europeans.

Funny you should say that.
Over here, it's the conservative folks who would do 180 in spite of the extra fuel.

Quote:

Don't bother ing that you're European and speed or whatever... The majority of cars in Europe are small and lack high
performance so you're automatically trapt in your continent's conservativeness!

Conservative people, at least in Europe, insist on driving huge smelly cars, while we dirty communists use public transport or bicycles, and sometimes we even walk.

Quote:

Besides, I'm only kidding. Germany makes cool cars. Italy makes semi-cool cars. It's the other countries that suck.

I don't really share your opinion here.
The last car I owned cost me 1400 €, and it took me wherever I needed to go, at reasonable speed (it could easily go 120 km/h, the general speed limit in the Netherlands). What would be the point in buying a car that costs 20 times that amount, would use more fuel, and were harder to park? Only that it looks cooler? Plus I'd spend all night worrying if my precious car were OK? Hmmm... I think I know better ways to spend my money.
Also, an Audi TT doesn't look THAT cool while almost touching my rear bumper, which expensive German cars somehow tend to do.
Also, a general speed limit makes sense; somewhere around 120-140 km/h, the danger involved simply outweighs the convenience of getting there a bit faster.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

Audric
Member #907
January 2001

Tobias said:

(...) if a single rest(1) statement causes the average frame time to rise by 14 ms, then something is wrong. Either with your computer, or with your code. (...)

If this is an effect of the granularity of the Windows scheduler, there's no programmer fault. It's very dependent on the actual OS version, and most of the information I could find on the web is for NT or 2000 versions, unfortunately.

Anyway, it's difficult to profile performance on a multi-tasking OS.

Tobias Dammers
Member #2,604
August 2002
avatar

But the granularity issue shouldn't cause an AVERAGE delay of 14 ms, but rather an OCCASIONAL one. Calling rest(1) a thousand times should still result in a delay of 1 second plus 1000 * the overhead for calling rest().

OTOH, it might still just be that.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

HoHo
Member #4,534
April 2004
avatar

I don't have Allegro installed at work, can anyone do a quick test to see if it really is so?

__________
In theory, there is no difference between theory and practice. But, in practice, there is - Jan L.A. van de Snepscheut
MMORPG's...Many Men Online Role Playing Girls - Radagar
"Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!" - Jakub Wasilewski

GullRaDriel
Member #3,861
September 2003
avatar

What is currently in test:

1#include <nilorea.h>
2 
3FILE *out;
4 
5int it = 1 ,
6 var = 0 ,
7 elapsed_time = 0 ,
8 med_time = 0 ,
9 rest_time = 1 ,
10 min = -1,
11 max = -1;
12
13N_TIME high_p_time ;
14 
15int main( int argc , char *argv[] )
16{
17 
18 if( argc > 1 )
19 {
20 if( sscanf( argv[ 1 ] , "%d" , &it ) == 0 )
21 it = 1 ;
22 }
23
24 if( argc > 2 )
25 {
26 if( sscanf( argv[ 2 ] , "%d" , &rest_time ) == 0 )
27 rest_time = 1 ;
28 }
29
30
31 allegro_init();
32 install_timer();
33
34 out = fopen( "result.txt" , "a+" );
35
36 fprintf( out , "Testing rest( %d ) %d times\n" , rest_time , it );
37
38 for( var = 0 ; var < it ; var ++ )
39 {
40
41 start_HiTimer( &high_p_time );
42
43 rest( rest_time );
44
45 elapsed_time = get_usec( &high_p_time );
46
47 med_time += elapsed_time ;
48
49 if( min == -1 && max == -1 )
50 {
51 max = elapsed_time ;
52 min = max ;
53 }
54
55 if( elapsed_time > max )
56 max = elapsed_time;
57 if( elapsed_time < min )
58 min = elapsed_time;
59
60 if( argc < 4 )
61 fprintf( out , "Iteration %d : %d usec , %d min , %d max \n" , var , elapsed_time , min , max );
62
63 }
64
65 med_time = med_time / it ;
66
67 fprintf( out , "Med_time : %d usec , min: %d , max: %d\n\n" , med_time , min , max );
68
69 fclose( out );
70
71 allegro_exit();
72
73 return TRUE;
74
75}END_OF_MAIN()

The results tells:

*Testing rest( 0 ) 1000 times
Med_time : 6 usec , min: 2 , max: 505

*Testing rest( 1 ) 1000 times
Med_time : 1984 usec , min: 1081 , max: 14009

*Testing rest( 10 ) 1000 times
Med_time : 10876 usec , min: 9818 , max: 22332

Here we are.

EDIT: Fixed min for displaying a wrong value, changing file opening to a+ , currently timing 100000 times for significant values. Will edit another time to attach the results.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Zaphos
Member #1,468
August 2001

Quote:

But the granularity issue shouldn't cause an AVERAGE delay of 14 ms, but rather an OCCASIONAL one. Calling rest(1) a thousand times should still result in a delay of 1 second plus 1000 * the overhead for calling rest().

Calling rest(1) a thousand times should result in a delay of (1 + overhead + GRANULARITY/2)*1000 ms at best. Because you have to wait your overhead, then your 1 ms, then the time it takes for the scheduler to come around again, which is on average half the granularity.

(In practice I think it could be worse than that because the sleep()-type queries in an OS tend to be specified as "sleep AT LEAST this long" with no particular upper bound, so if they have to wake a whole bunch of processes up at once they can still keep the scheduler running in constant time by waking only one process per interrupt.)

Ron Ofir
Member #2,357
May 2002
avatar

GullRaDriel: Those max values look really weird. One time you called rest(1) and it waited for 14 seconds? That doesn't make any sense!

HoHo
Member #4,534
April 2004
avatar

Quote:

One time you called rest(1) and it waited for 14 seconds?

μsec!=msec.

Though μsec aka microsecond is 1/1000,000'th of a second, not 1/10,000'th

__________
In theory, there is no difference between theory and practice. But, in practice, there is - Jan L.A. van de Snepscheut
MMORPG's...Many Men Online Role Playing Girls - Radagar
"Is Java REALLY slower? Does STL really bloat your exes? Find out with your friendly host, HoHo, and his benchmarking machine!" - Jakub Wasilewski

GullRaDriel
Member #3,861
September 2003
avatar

Testing from 0 to 10 millisecond said:

Testing rest( 0 ) 100000 times
Med_time : 4 usec , min: 2 , max: 4927

Testing rest( 1 ) 100000 times
Med_time : 2083 usec , min: 988 , max: 25731

Testing rest( 2 ) 100000 times
Med_time : 3019 usec , min: 1970 , max: 18255

Testing rest( 3 ) 100000 times
Med_time : 4057 usec , min: 2952 , max: 28395

Testing rest( 4 ) 100000 times
Med_time : 4986 usec , min: 3922 , max: 23558

Testing rest( 5 ) 100000 times
Med_time : 5956 usec , min: 4909 , max: 24927

Testing rest( 6 ) 100000 times
Med_time : 6943 usec , min: 5888 , max: 23677

Testing rest( 7 ) 100000 times
Med_time : 7918 usec , min: 6862 , max: 24174

Testing rest( 8 ) 100000 times
Med_time : 8888 usec , min: 7842 , max: 28967

Testing rest( 9 ) 100000 times
Med_time : 9780 usec , min: 8814 , max: 22391

Testing rest( 10 ) 100000 times
Med_time : 10746 usec , min: 9795 , max: 19646

All times are microseconds, not millisecond or second.

i.e: When it says max: 23677 it means that it has wait for 23.677 milliseconds.

All those results gave us the following picture:
{"name":"591727","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/1\/01c695fd33c10887dd9e063afdaab1b1.jpg","w":979,"h":461,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/1\/01c695fd33c10887dd9e063afdaab1b1"}591727

As you can see the minimum value is generally following the expected value. It is not really the case with the maximum value...

Conclusion: do not use rest for timing stuff.

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Kris Asick
Member #1,424
July 2001

As I've said before, the only reason you'd want to use rest(1) or Sleep(1) over rest(0) or Sleep(0) is to avoid issues with stalling the keyboard, mouse and joystick input. But I'm working on solving that issue and I think I have a solution, but I have no idea how to program it. (Though it shouldn't take more than a couple minutes to do for someone who does know how.)

Here's a forum link to my recent post discussing the possibility of solving that issue: http://www.allegro.cc/forums/thread/590832/662625

But it's good to know that the rest() and Sleep() statements may burn tons of time because it explains some of the framerate troubles I've seen in my games on specific (usually lower end) systems.

--- Kris Asick (Gemini)
--- http://www.pixelships.com

--- Kris Asick (Gemini)
--- http://www.pixelships.com

Jonatan Hedborg
Member #4,886
July 2004
avatar

Sounds like a good place for a slider in the options menu (for whatever game you are making) then.

No resting - Yielding - Resting
(for best performance) (recomended) (when you don't want to use all CPU (power saving mode))

 1   2 


Go to: