|
This thread is locked; no one can reply to it. |
1
2
|
rest(1) 65 fps!? |
Kitty Cat
Member #2,815
October 2002
|
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. -- |
Albin Engström
Member #8,110
December 2006
|
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 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
|
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: __________ |
Albin Engström
Member #8,110
December 2006
|
that may be right.. i think i'm going to make something now, something small that is.. |
bamccaig
Member #7,536
July 2006
|
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? -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
Tobias Dammers
Member #2,604
August 2002
|
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. Oh, and on the car analogy: --- |
Albin Engström
Member #8,110
December 2006
|
{ 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
|
Quote: the code does not look like this of course..
Then what does it look like? 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. --- |
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) --- Kris Asick (Gemini) |
Albin Engström
Member #8,110
December 2006
|
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
|
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. -- acc.js | al4anim - Allegro 4 Animation library | Allegro 5 VS/NuGet Guide | Allegro.cc Mockup | Allegro.cc <code> Tag | Allegro 4 Timer Example (w/ Semaphores) | Allegro 5 "Winpkg" (MSVC readme) | Bambot | Blog | C++ STL Container Flowchart | Castopulence Software | Check Return Values | Derail? | Is This A Discussion? Flow Chart | Filesystem Hierarchy Standard | Clean Code Talks - Global State and Singletons | How To Use Header Files | GNU/Linux (Debian, Fedora, Gentoo) | rot (rot13, rot47, rotN) | Streaming |
HardTranceFan
Member #7,317
June 2006
|
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. -- |
Tobias Dammers
Member #2,604
August 2002
|
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. Quote:
Don't bother ing that you're European and speed or whatever... The majority of cars in Europe are small and lack high 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. --- |
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
|
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. --- |
HoHo
Member #4,534
April 2004
|
I don't have Allegro installed at work, can anyone do a quick test to see if it really is so? __________ |
GullRaDriel
Member #3,861
September 2003
|
What is currently in test:
The results tells: *Testing rest( 0 ) 1000 times *Testing rest( 1 ) 1000 times *Testing rest( 10 ) 1000 times 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" |
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
|
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
|
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 __________ |
GullRaDriel
Member #3,861
September 2003
|
Testing from 0 to 10 millisecond said:
Testing rest( 0 ) 100000 times Testing rest( 1 ) 100000 times Testing rest( 2 ) 100000 times Testing rest( 3 ) 100000 times Testing rest( 4 ) 100000 times Testing rest( 5 ) 100000 times Testing rest( 6 ) 100000 times Testing rest( 7 ) 100000 times Testing rest( 8 ) 100000 times Testing rest( 9 ) 100000 times Testing rest( 10 ) 100000 times 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: 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" |
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) --- Kris Asick (Gemini) |
Jonatan Hedborg
Member #4,886
July 2004
|
Sounds like a good place for a slider in the options menu (for whatever game you are making) then. No resting - Yielding - Resting
|
|
1
2
|