Quote:Original post by IndigoStallion When you are in Fullscreen, the framerate is limited to the refresh rate. (60hz, 72hz, etc)
the easiest way to get around this is to impliment a timer function and limit your program to the framerate you want(usally 30fps), and for your polygon updates, use a function like:
Actually, I think the easiest way to get around this is to simply disable it. You can do it by setting your
Right now, you aren't setting it at all, defaulting it to D3DPRESENT_INTERVAL_ONE.
Uhmm circlesoft pointed out the problem and solution(above), seems too much misinformation causes more misinformation. Stick the the real solution to the real problem.
-------------Become part of developing the specifications of a new language. Visit CodeBASIC.org
My program has the same problem too.I have frame rate lock capability in my engine(locked to 60 fps with monitor refresh rate=60hz),but still,teariing is so obvious when objects are moving very fast in the scene.Any idea on this ?
The only way to always guarantee a constant game speed without locking the frame rate is just to take the time delta between the frames, and multiply all of your object velocities by it. If you're measuring the time delta in seconds, your velocities would be per second, giving you some idea of how much the object would move / rotate in a given time frame. Note that if you're using mouse delta to do movement, you do NOT multiply by the time delta, because the mouse delta is time-based anyways. Hope that helps. Happy coding.
Just a supplemental question if you guys don't mind-
I've been scaling my variable processing by time_delta's for a while now, but I always use the time_t data type and clock() MS provides for keeping track of time. Is there a faster/more efficient way?
Sorry to ask the obvious, but which size is your window?
I mean, we can see your fullscreen is 1024*768, but you dont tell the size of your window. In a larger screen, more pixels are drawn, so it takes longer to draw. So if you window is 300*300 then you have a window about 1/8 of the 1024*768. So it can be faster to draw a tiny window than a fullscreen.
In my engine, 320x240 fullscreen is horribly slow and 320x240 windowed is amazingly fast (after all, it only has to draw a handful of pixels). 1024x768 seems to be the optimal reselution for my engine, though 800x600 works very well too
You can look at the "SkinnedMesh" tutorial from the DirectX9.0c (summer update) SDK and how it uses (float) fEnlapsedTime in OnFrameRender() and OnFrameMove() fonctions and everywhere constant game speed is needed.
I would like to say never let the fps run wild and high. Lock it but lock it high. Make sure you have room for slowdowns. 60fps is a great place to get the game locked to. pgr2 is at 30fps just to let you know. just my 2 cents
Is vsyncing then bad because it locks the framerate? Since it's set to the monitor's refresh rate, it should be capped out somewhere between 60 and 100 fps, which seems like enough. Also, I have not experienced it myself but as someone else already mentioned tearing could be a problem.
60 fps is a terrible place to lock your framerate. It is WAY too low. 100fps looks so much better, assuming your refresh rate is good, but even locking at 100fps is unacceptable.
Vsync is bad because it locks the framerate and the leftover time is wasted. If your game is cruising at a vsync'd 100fps and the action gets hot you might fall to 50 fps for a short time. Which looks terrible. (Remember that fluctuations in frame rate are the most noticeable, even to casual gamers.)
With vsync off, if your game is cruising at 200fps and things get heavy, you might fall to 110fps. As long as this lower fps is still above your refresh rate things will continue to look good. Any (modern) game locked at 30-60fps is poorly implemented IMO.
Of course this refers to the rendering pipeline, the logic/collision/AI/etc pipelines can afford to be updated much less often.
