yeah that doesnt make sense, i probably miscoded something
Limit FPS?
Another point is you shouldn''t really let you app "run free" with no fps limiting. Although Windoze should cope with this I find it is usually better to hold the frame rate back with a Sleep(n). This gives Windoze some time to do other stuff. This is esp noticable on win9x.
I ususally let the game code run between 25-60fps, and the gfx around 60-85fps ( although this does depend on your monitors refresh rate ).
[IMHO]
I think people should not get to hung up on getting 100+ fps, the most important thing is a constant frame rate. If the frame rate is varying wildly (30-60, 60-100+) the user is going to notice this a lot more than a app constantly running at 30fps!
And disabling VSync just to get a more impressive frame rate is bad, since the resultant tearing looks ugly
[/IMHO]
Mark Duffill[The Jackal]
Eurocom Entertainment Software
I ususally let the game code run between 25-60fps, and the gfx around 60-85fps ( although this does depend on your monitors refresh rate ).
[IMHO]
I think people should not get to hung up on getting 100+ fps, the most important thing is a constant frame rate. If the frame rate is varying wildly (30-60, 60-100+) the user is going to notice this a lot more than a app constantly running at 30fps!
And disabling VSync just to get a more impressive frame rate is bad, since the resultant tearing looks ugly
[/IMHO]
Mark Duffill[The Jackal]
Eurocom Entertainment Software
quote:Original post by Mark Duffill
Another point is you shouldn''t really let you app "run free" with no fps limiting. Although Windoze should cope with this I find it is usually better to hold the frame rate back with a Sleep(n). This gives Windoze some time to do other stuff. This is esp noticable on win9x.
I ususally let the game code run between 25-60fps, and the gfx around 60-85fps ( although this does depend on your monitors refresh rate ).
[IMHO]
I think people should not get to hung up on getting 100+ fps, the most important thing is a constant frame rate. If the frame rate is varying wildly (30-60, 60-100+) the user is going to notice this a lot more than a app constantly running at 30fps!
And disabling VSync just to get a more impressive frame rate is bad, since the resultant tearing looks ugly
[/IMHO]
Mark Duffill[The Jackal]
Eurocom Entertainment Software
Why not let it run free? I''ve never met person who can play quake in a window and type a paper at the same time...
quote:
Why not let it run free? I''ve never met person who can play quake in a window and type a paper at the same time...
I was on about windows house keeping tasks it does in the background. Although you could give writting an essay + quake a go
I don't understand something said further above:
Have the game simulate at 20 fps and display at 80 fps.
Thats not neccesary if you ask me, because then you'd only draw the same scene 4 times and no change to the content.
I'd rather have it reversed. Calculating physics faster than the graphics, with graphics at 30+ fps. That at least would give you a higher accuracy and since the scenes will only change marginally you could do much optimizations.
[edit] slight rephrasing
---------------------------
I may be getting older, but I refuse to grow up
[edited by - Dreamforger on July 17, 2002 3:08:40 PM]
Have the game simulate at 20 fps and display at 80 fps.
Thats not neccesary if you ask me, because then you'd only draw the same scene 4 times and no change to the content.
I'd rather have it reversed. Calculating physics faster than the graphics, with graphics at 30+ fps. That at least would give you a higher accuracy and since the scenes will only change marginally you could do much optimizations.
[edit] slight rephrasing
---------------------------
I may be getting older, but I refuse to grow up
[edited by - Dreamforger on July 17, 2002 3:08:40 PM]
Most games run physics slower than they draw the graphics, at least in the FPS world. Quake, Quake 2, and Half-Life (and probably others but I''m only sure on those 3) run the physics only about 10 times a second, but the graphics can be drawn up to 100 times a second in half-life. The ''extra time''(between physics updates) is spent interpolating between animations and smoothly moving models from one place to another (you get 10 frames of motion between point A and B instead of only 1, and that makes motion look a lot smoother).
Also, I would suggest that fps not be limited to lower than 100. Sure most monitors now max at 85hz refresh rate but leave a little growing room for the future. Also, as somebody said, constant fps is better than high and low alternation, so try to code the game to find a nice stable fps rate =-) Just take the average fps over a short time, and limit the fps to that + 10 or something (to allow it to increase in case it was just a moment of windows processing in the BG or maybe one scene that was really complex)
"The Requested Information Is Unknown Or Classified" -Anonymous
Also, I would suggest that fps not be limited to lower than 100. Sure most monitors now max at 85hz refresh rate but leave a little growing room for the future. Also, as somebody said, constant fps is better than high and low alternation, so try to code the game to find a nice stable fps rate =-) Just take the average fps over a short time, and limit the fps to that + 10 or something (to allow it to increase in case it was just a moment of windows processing in the BG or maybe one scene that was really complex)
"The Requested Information Is Unknown Or Classified" -Anonymous
quote:Original post by Mark Duffill
Why not let it run free? I''ve never met person who can play quake in a window and type a paper at the same time…
I was on about windows house keeping tasks it does in the background. Although you could give writting an essay + quake a go
Oh. I don''t think those take too much time and windows will just take what it needs, causing a slight drop in the FPS. Personally I hate it when games take up a small percentage of my memory and processor and then run slow… So I set the process to realtime. But still, you do have a point, it''s just limiting it to 30FPS is silly.
quote:Original post by Dreamforger
I don't understand something said further above:
Have the game simulate at 20 fps and display at 80 fps.
Thats utter bogus if you ask me, because than you'd only draw the same scene 4 times and no change to the content.
I'd rather have it reversed. Calculating physics faster than the graphics, with graphics at 30+ fps. That at least would give you a higher accuracy and since the scenes will only change marginally you could do much optimizations.
Nope. It really is good to do the physics at a fixed rate and let the graphics run free. The trick is to do some interpolation or extrapolation during the draw calls, so you can animate between the positions the physics code comes up with.
You usually _don't_ want the physics to run faster than the graphics. If you want a multiple step integrator the proper thing to do is to integrate to a higher accuracy in one physics call, not call physics multiple times per drawn frame. Besides, if you run physics too fast, you can't keep up on all PCs and you end up losing the repeatable behavior that makes fixed framerates so attractive in the first place.
[edited by - cheesegrater on July 17, 2002 10:18:43 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement