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.

What happens if you do rest(0)?

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

What is the FPS otherwise?

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.

I didn't ask how fast it is without the rest, I asked if it is too slow to be playable. There is a difference.

I wouldn't worry about speed unless your program runs unplayably slowly with the final graphics and effects. Trying to optimize stuff that runs at several hundred FPS is just not a waste of time.

My guess is that rest(1) uses the OS thread schedular granuality, on Windows that should be around 15-16ms. On Linux it can be from 1-10ms. That means every time you call rest with >0 parameter you will rest at minimum the it takes the OS to do a context switch.

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

I thought if you limited your logic and drawing to a certain framerate, rest(0) would make sure your program didn't use 100% CPU time. At least I think it was like that at one point...

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

I've tinkered around with this lately.

First off, rest(1) shouldn't have that huge of a difference on your fps. I was running my game at 90fps (average), added rest(1), and it went to 89fps (average). Thus, you probably have rest(1) at a weird spot. I only do rest(1) when I'm ahead, like so (writing code from memory):

If perhaps you put the rest(1) in the function used as the hardware interrupt, yeah, fps is going to suffer significantly.

My program seems to be pretty intensive, rest(0) seems to give nothing back to the PC, rest(1) a smidget, and rest(10) gives a decent amount, although makes the game lag somewhat.

[edit]
Also, 65fps is not a bad number! 600 is ridiculous, your monitor can't even draw that much. Throw in a vsync and you'll see a more realistic number.

'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.

Highly depending on what kind of changes there are between sequental images. In cinema you see 11FPS movie and think it is nice and fluid. At home you or at least some people can separate individual frames in FPS running at >50FPS

A ninja can see 7000+.

I doubt you would, actually. Unless you added so much blur you'd think the projector operator was legally blind.

A whole lot.

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.

Albin, I have the same result as you for my game. If I don't use rest(x), it's around 350fps. If I put in a rest(1), it drops to 64fps. The game runs at 64fps no matter how much I push around the screen, so I'm not that bothered by it.

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.

I wonder where I heard about 11FPS, it should be around 18FPS actually. Sorry about the confusion.

Please measure the CPU usage also. If it is less than 50% you can stop further measurements and start writing the game!

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.

Light speed fps? Now, that's my kinda computer. Imagine the amount of processing, computations and graphics you could push through that baby. Windows might just work at a reasonable speed on it.

HardTranceFan: ...

but it's not right? :S that enough is reason.

15 fps.... that's overkill.. - -, it's not about 'seeing' the frames, it's about the feeling of smoothness.

haha, that's what i want to do too.. but every time i start to "make a game" it ends because i know of a better way to do it - -. it just isn't fun to write code when the rest of the code sucks.. i have a scrapyard with about 600 files and 127 folders, and that's after i've cleaned it up..

that's NOT my case.. and the difference between X fps and X+ fps is visible! ok, "can't" see the frames, but thats the point, isn't it? the higher fps the smoother the movements, that's not a theory, it's a fact! i absolutely don't want a fps higher than what the monitor can display.

and 64 sucks!! if i have a monitor able to do 120(mine does 75) why would i want 64?? and for the second time: it IS visible. i don't understand why people can't see it..

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.

nm

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

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.

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

que?

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.

that's outrageous!

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

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

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?

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.

{
  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"?

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.

Yes it was...

Then why do you want 600 fps?

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.

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

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

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

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.

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.

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.

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.

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.

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

I meant something that actually compiles.

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

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.

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.

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.

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.

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

What is currently in test:

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.

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.)

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!

μsec!=msec.

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

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"}

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.

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

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))