Archived

This topic is now archived and is closed to further replies.

Any ideas how to limit DX9 FPS?

This topic is 5009 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Get the time at the start of the frame (starttime), render the frame and wait until starttime+(1000/desiredfps)>=currenttime and then start over again.

[edited by - Randy187 on March 29, 2004 9:02:56 AM]

Share this post


Link to post
Share on other sites
Use time based everything ( distance traveled = timePassed * velocity for example ) What happens if the computer is slower than your framerate? And if it is faster than you lose FPS ( bad )

Share this post


Link to post
Share on other sites
quote:
Original post by VolkerG
The big question is: Why would you like to do that?


If you don''t limit FPS, your app basically dominates the system, taking all of the CPU''s spare time (watching task manager will show your app running at 98+% CPU usage). If all the user is doing is running your app, this is probably OK. But if you can free up some of that CPU usage without degrading your visuals, why not? The human eye can''t see any difference between 200fps and 100fps. Heck anything over about 40 or 50 fps is going to appear "smooth". Even television is 24 fps (digital is 30, I think).

If you can keep your FPS down, you free up the CPU for other things if needed.

Share this post


Link to post
Share on other sites
quote:
Original post by BriTeg
quote:
Original post by VolkerG
The big question is: Why would you like to do that?


If you don''t limit FPS, your app basically dominates the system, taking all of the CPU''s spare time (watching task manager will show your app running at 98+% CPU usage). If all the user is doing is running your app, this is probably OK. But if you can free up some of that CPU usage without degrading your visuals, why not? The human eye can''t see any difference between 200fps and 100fps. Heck anything over about 40 or 50 fps is going to appear "smooth". Even television is 24 fps (digital is 30, I think).

If you can keep your FPS down, you free up the CPU for other things if needed.


well, I just realized that the Sleep thing is not good, because it''s not delay just the graphics, it''s delaying all the damn computer...

Share this post


Link to post
Share on other sites
Are we talking about a game running in fullscreen (no need to give too much CPU to ather processes) or about a windowed application ("more" intelligent sharing of the CPU time)?

Share this post


Link to post
Share on other sites
if the app is a fullscreen game the why not let it blast away with 100% cpu?
if its not a fullscreen app but its a rendering window in, say a model loading/viewing/editing app then only draw when you need to, by handling WM_PAINT or WM_ERASEBKGND and using RedrawWindow to tell it to draw when some aspect of the scene has changed.

Share this post


Link to post
Share on other sites
Don''t waste the precious cycles!
While sleep is going you could have instead done a couple more pathfinding loops or done somne preloading or whatever.

Share this post


Link to post
Share on other sites
quote:
Original post by Ilankt
well, I just realized that the Sleep thing is not good, because it''s not delay just the graphics, it''s delaying all the damn computer...


No, Sleep only suspends that thread. All other running threads are not affected, except potentially positively by having the CPU more available.

Share this post


Link to post
Share on other sites
quote:
Original post by BriTeg
quote:
Original post by Ilankt
well, I just realized that the Sleep thing is not good, because it''s not delay just the graphics, it''s delaying all the damn computer...


No, Sleep only suspends that thread. All other running threads are not affected, except potentially positively by having the CPU more available.




even if I dont use threads in my game?

Share this post


Link to post
Share on other sites
quote:
Original post by BriTeg
If you don''t limit FPS, your app basically dominates the system, taking all of the CPU''s spare time (watching task manager will show your app running at 98+% CPU usage).
Just. Plain. Wrong.

You do realize you could maximize CPU usage without drawing anything? And you do realize that Windows is a preemptive multi-tasking operating system? You also realize that "99%" CPU utilization is not a bad thing, given that the CPU is otherwise running below peak?

If you absolutely must think about other programs, insert a Sleep(0) at the end of your game loop. Do not limit frame rates; interpolate instead (time-based movement, physics, AI, etc).

quote:
The human eye can''t see any difference between 200fps and 100fps. Heck anything over about 40 or 50 fps is going to appear "smooth". Even television is 24 fps (digital is 30, I think).
No. HDTV is 60 fps; NTSC is 30; film is 25 - in the US. HDTV in Europe is 50 and PAL is 25. The differences are due to the frequencies at which AC voltage is delivered - 60Hz in the US, 50 in Europe. In other words, the frequency of television was not determined solely by ergonomic factors, but also by engineering ones and thus is no basis upon which to argue a reasonable framerate for games.

Run flat-out, if possible. The more rapidly the frames are refreshed, the smoother the image is to the eye. I know some people who can see flicket at 70Hz on CRTs.

Share this post


Link to post
Share on other sites
quote:
Original post by Ilankt
even if I dont use threads in my game?


Sorry, I should have been more clear. Most apps, like your game, are single-threaded. Thus Sleep would suspend only your app, not other apps running on the system. If you were to use multiple threads in your app, Sleep would only suspend the thread it was called from.

Share this post


Link to post
Share on other sites
set up a timer and call your drawing function from the timer instead of on idle time. i don't know what sleep does but it sounds like its just wasting cycles.

[edited by - phongor on March 29, 2004 1:47:44 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
quote:
Original post by BriTeg
If you don''t limit FPS, your app basically dominates the system, taking all of the CPU''s spare time (watching task manager will show your app running at 98+% CPU usage).
Just. Plain. Wrong.



Not wrong. Most games and graphics demos set up the main game loop to loop as fast as possible, rendering like crazy when there are no Windows messages to process. Thus, the CPU usage skyrockets. Try running any app in Windowed mode that is set up with a game loop like this, hit Ctrl-Alt-Del to open up task manager, sort the processes by CPU usage, and you''ll see the app right at the top with average 97-99% CPU usage.

quote:

You do realize you could maximize CPU usage without drawing anything? And you do realize that Windows is a preemptive multi-tasking operating system? You also realize that "99%" CPU utilization is not a bad thing, given that the CPU is otherwise running below peak?



Yes, I realize all those things.

If you have two apps running with a loop like that, they basically split the CPU, each app running at 48-49%, and running at half-speed. Running three apps will give each approx 1/3, and each will run at approx 1/3 speed. Have you ever tried to run a full-screen game (with a game loop as described above), while running another app that also is running as fast as possible (e.g. searching/downloading crap in the background with KazaaLite, etc.)? Your game runs half as fast, because the CPU is splitting between the game and the other app.

quote:

If you absolutely must think about other programs, insert a Sleep(0) at the end of your game loop. Do not limit frame rates; interpolate instead (time-based movement, physics, AI, etc).



I agree iterpolation is usually the better choice - but it depends on the game. It''s also a bit more work to implement.

quote:

HDTV is 60 fps; NTSC is 30; film is 25 - in the US. HDTV in Europe is 50 and PAL is 25.



Whatever. The point is, you don''t need 745 fps to play Tetris or Super Mario Brothers. Or even Unreal Tournament. Why hammer the CPU like that to achieve frame rates that are absurd and make no difference? Why not put in a little effort to be nice to your fellow apps?

quote:

Run flat-out, if possible. The more rapidly the frames are refreshed, the smoother the image is to the eye. I know some people who can see flicket at 70Hz on CRTs.


A refresh rate of 60 Hz gives me a headache after a while, I need 85 or higher to be comfortable. But when I''m playing a game, I could care less if it''s running at 80 fps or 800 fps - it''s unnecessary overkill. I don''t agree that running flat out is always best. For many scenarios, it''s fine (i.e. it doesn''t hurt), but sometimes not. I wrote a DirectX screen saver, and I know of some network admins that are running it on their main servers at work - if I ran it flat out, without specifically yielding CPU in my main loop, they''d never use it because it would affect server performance for dozens of people.

Share this post


Link to post
Share on other sites
Are you blithely suggesting that the usage contexts of a game and a screensaver are equivalent?

Most games are built around the assumption that they will be the sole major application running - and most gamers run them that way. We''re talking triple-A, "push-the-envelope" titles here. Yes, for your little Tetris clone, running flat-out is hardly necessary. Neither is using DirectX or C++: you could write it in an environment that does all this for you.

You''re absolutely right, though. Running flat-out isn''t always the best. In controlled contexts, however, it''s a better solution.

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Are you blithely suggesting that the usage contexts of a game and a screensaver are equivalent?



Give me a break. The concepts are the same, the main loop is the same. It was just an example. Why are you so antagonistic?

quote:

Most games are built around the assumption that they will be the sole major application running - and most gamers run them that way.



Yes, exactly. "assumption". "most".

Share this post


Link to post
Share on other sites
Perhaps one of you can tell me the advantage of throwing frames at the monitor at a rate faster than the monitor is refreshing? I don''t see the point of that.

If you have more time left over after running at monitor refresh rates, turn on FSAA or some other features that will make the game''s graphics look better, don''t go generating more frames.

Also think about the poor schlep running on a battery powered device. Don''t burn his battery just because you can. This becomes a more serious issue if you begin to develop games for wireless phones.

BTW, motion picture film is 24 fps (not 25).

Share this post


Link to post
Share on other sites
quote:
Original post by don
Perhaps one of you can tell me the advantage of throwing frames at the monitor at a rate faster than the monitor is refreshing? I don''t see the point of that.
By monitoring your FPS during development, you can make sure that the new algorithms you just added aren''t slowing down your game by an unreasonable amount. Also, during times of high system load, it ensures that your game will still have a playable FPS, despite the considerable drop. I''m not sure why you would want to disable vsync in release mode, though.

Share this post


Link to post
Share on other sites
Want to see the person that plays a game and uses word at the same time. I don''t tink that you would get any big advantage by limiting the framerate (ok, you may sync rendering with the refresh rate, but that''s another topic).
Sure, there may be exceptions and if the game would run in windowed mode you should share the CPU with other processes more carefully. But a fullscreen game, with exculsive DirectInput access and all the fancy stuff must not bother with that stuff (at my opinion).

Share this post


Link to post
Share on other sites