Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 12 Aug 2013
Offline Last Active Sep 09 2013 04:43 AM

Posts I've Made

In Topic: VSync messing with QPC() timing?

13 August 2013 - 10:30 AM

Speaking of which, I tried obtaining the swap chain pointer from the device (using GetSwapChain) and calling Present from that (it has a flag parameter, like PresentEx), but D3DPRESENT_DONOTWAIT didn't have any effect. As it happens, my laptop has Intel and NVidia GPUs.


That said, is PresentEx any different from what I've tried? Should I give it a go nonetheless?


Update: I've come across an article describing the use of GetRasterStatus to determine if the frame is still being drawn. Adding this to my second timer check (so the render function isn't called until the display has finished drawing) seems to have fixed the problem.

Just in case, the second check now looks like this:


Are there any potential problems I'm not seeing?

In Topic: VSync messing with QPC() timing?

13 August 2013 - 07:50 AM

If the refresh rate is at 60HZ and your rendering consistently at 59HZ i is going to duplicate frames. If you cant use a Present like I mentioned (I just looked at the IDXGISwapChain and it seems to have flags to do so for Present) then I think you need to render at slightly above the refresh rate, so that it still gets all the frames it needs, with minimum time spent waiting on a vsync.

Since you've mentioned IDXGISwapChain, does your method require DirectX 10 or higher?


Have you got D3DCREATE_FPU_PRESERVE in your CreateDevice call?  If not I'd suggest that you put it in there as a temporary workaround, and doing so should resolve your problem, which sounds an awful lot like you're accumulating time deltas and suffering from floating point precision loss in the accumulation.

Sadly, adding the flag did nothing. I've mentioned before that, as per Hodgman's suggestion, this is probably a frame queueing problem.

In Topic: VSync messing with QPC() timing?

13 August 2013 - 05:24 AM

In response to Hodgman:

Thanks for the information on VSync and GPU queueing, it does indeed seem that frames were being fed to the display faster than it could draw them. I've slightly lowered the render function call frequency and the slowdowns seem to have ceased. I don't suppose it's too much of a crutch to render at (screen update rate)-1Hz if VSync is enabled? happy.png


As for my physical calculations, I've only just started figuring them out (hence the extreme update rate, for instance - I've decided to play it safe to avoid collision skips and such, but looks like I've overdone it). Thanks for everyone's suggestions, I'll definitely make use of them.

In Topic: VSync messing with QPC() timing?

12 August 2013 - 10:00 AM

Yes, that is what Hodgman is saying; vsync blocks until the display is ready for another frame.

But why does the slowdown only occur after several seconds, then? To clarify, at first everything is just like without VSync, with phystick showing 16-17 every frame (that's got to mean first "if" fires 16.(6) times as often as the second one... right?). Then it slowly drops. And even so, it stays higher than 1, so "while(true)" must be firing at more than 60Hz.

In Topic: VSync messing with QPC() timing?

12 August 2013 - 09:27 AM

Um, I didn't quite get it. Are you saying VSync stalls the rendering function until the display has finished drawing the previously presented frame? So the "while(true)" only fires once every 16.(6) ms?


Regarding the "physicsAccumulator": I've considered passing the time since the last physics iteration to ProcessPhysics(), so that it would advance the game world by that amount, but then, if a game were to freeze momentarily, there would be a skip. I thought it would make quite a mess of things, so I've decided to use a fixed step size.