ok.. when i use rest(1) my game fps drops to 65(64)! in both double and triple buffering. i searched the forums and found an abandoned thread about this, so lets get on with this unfinished business!

heres the thread: http://allegro.cc/forums/thread/585737

i have no memory of this problem at home (i'm in school now).

i don't know what to say so... i'll let you do the talking.

Is 65FPS too little?
What is the CPU usage?

rest(0) acts the same as no rest(x) at all.

"Is 65 FPS too little?"

yeah, without rest(1) the fps is almost 600 in double buffering.
with rest(1) 64..

i don't have time to test triple buffering, i'll post a result as soon as i get home.

Perhaps your FPS will stay at around 65 even if you add another million things to render per loop.

No, rest(0) give processor back to other process if they need it. If not, you will keep eating the CPU.

'An average 17" monitor can reach 85 Hz, meaning that any performance reached by the game over 85 fps is discarded.' - Source

I'm no video expert, but I've always thought that 60 fps was great. According to that same article, Rockstar's GTA games are limited to 25-30 fps. How fast can the average human process an image anyway? 600 fps is insane! There's no point consuming cycles with your game if it doesn't need them.

A ninja can see 7000+.

ok.. sorry for the delay.. anyway:

double buffering | windowed | rest(0) | using vsync = 75 fps (correct)
double buffering | windowed | rest(0) | without vsync = 125 fps (unsure)

double buffering | fullscreen | rest(0) | using vsync = 75 fps (correct)
double buffering | fullscreen | rest(0) | without vsync = 155 fps (unsure)

double buffering | windowed | rest(1) | using vsync = 75 fps (correct)
double buffering | windowed | rest(1) | without vsync = 112 fps (unsure)

double buffering | fullscreen | rest(1) | using vsync = 75 fps (correct)
double buffering | fullscreen | rest(1) | without vsync = 135 fps (unsure)

triple buffering | rest(0) = 64-70 fps (??)
triple buffering | rest(1) = 75 fps (correct)

hmm, i don't think there's anything wrong here.. but then again it wasn't on this computer i discovered it.

the only thing i can think of now is: why does my computer get 1/4 fps in un-v-sync:ed double buffering of the computer in school? as far as i can tell, my computer is far superior..

i'm going to school tomorrow morning and take some tests there.. i remember the monitors refresh rate where 85, but i could get past 64 in some cases.

Hey, what's the matter with those FPS, unless it drops bellow 30, there's no need to worry. Movie is ussually shot at 24 FPS. Even if you have Quake 3 running at 15 FPS, you're not likely to see the actual frames. Besides 600 is evil, it eats 100% of CPU and therefore consume my battery on laptop.

People always want to have the quickest thing even when it is not needed.

Example:
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.

HardTranceFan: ...

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.

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.

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