   Setting the refresh rate
  I was just wondering whether rather than messing about with frame rate independant movement and so on, it was "safe" to set the FullScreen_RefreshRateInHz of the D3DPRESENT_PARAMETERS to 60 when setting up the device.I mean "safe" in the sense of:a) Will the attempt fail if the user's monitor doesn't support 60hz?b) Are there actually any hardware set ups that don't support 60hz?c) Can this setting be over-ridden by local settings?I've tried every possible way I can think of to get frame-rate independance in a Mario-style 2D jumping scroller and nothing seems to be working. Variable physics and frame rate leads to different height jumps at different frame rates and fixed rate physics and variable framerate leads to stuff shaking around on the screen, even with various different interpolation methods that I've tried.I just want it to look rock-solid like it would on a NES or Gameboy and I'm coming to the conclusion that fixed physics fixed framerate is the only option.I appreciate that on a machine too slow to render at 60fps the game will not run properly but I don't really care about that.Thanks in advance.[EDIT] I've just discovered that I can test for the support of a refresh rate via EnumAdaptorModes, so I guess that answers question a). Questions b) and c) I'd still be interested to know people's thoughts on though.[Edited by - EasilyConfused on December 11, 2006 5:32:16 AM]
  Well your level in DirectX programming is probably far above mine, but the book I was reading uses timers to setup the clients refresh rate.  Using the Performance Counter it only allows the application to render once every second.  I'm not sure how this will be effected though if you were running a much slow computer. Give it a shot, that could be what you are looking for possible.   ;  I'd recommend you avoid attempting to manually time the refresh rate for the drawing. There are too many factors, it won't be simple to do.What I'd recommend you do is something similar to XNA's method for handling updates. Seperate your loop into an Update and a Draw. Call Draw as fast as you can, and call Update between Draw calls. The number of times you call Update depends on the amount of time that's passed since the last update. If, for some reason there was a quick frame, you might skip calling Update completely. If the frame took a long time, you might want to call Update twice to make up for the missing updates that should have been done "mid-frame".The result of this kind of set-up is a constant-frame-time animation that isn't framerate dependent.You could enable VSync, and the animation should still run at a constant speed, as long as the timing methods return relatively accurate results.Hope this helps.   ;  Cheers for the input.@sirob - that was the last thing I tried, and even extended it to do some interpolation based on the amount left in the accumulator each frame. No dice - still really jittery. Thanks anyway, though.My last game used proper frame-rate independant physics and rendering but didn't matter since it didn't need to be so precise.I'm going with setting the refresh rate on this one. I'm querying to ensure the rate is supported with EnumAdaptorModes() and a couple of people have tested the demo (in my Journal if you fancy trying it) without problems.Basically, if your display doesn't support 1024x768x32 at 60hz, my game won't run. I don't think that will affect many hardware set ups but anyone who has a setup that can't support that, please let me know since I want to get an idea of how common such setups are.   