scrollpic stutters
category: general [glöplog]
Try using an audio timer (waveOutGetPosition or IDirectSoundBuffer8::GetCurrentPosition) instead of the performance counter. They have a fixed rate, high resolution, and tell you directly what you actually want to know (which sample of the music is currently playing).
Yesterday after a Windows fuckup I've enabled most services to get back all functionnality.
Then I had the same stuterring thing described here. If I drawed quads on my scene it would be dead slow (38 fps) and stutter (~ 1 time/second). I tried to smooth the time step and to reduce filtering quality, but the problem was still here.
In the end I just deactivate unuseful Windows services (using a recommandation list from the Internet) and rebooted, and the problem was gone. There must be one which fuck up things.
Hope it helps.
Then I had the same stuterring thing described here. If I drawed quads on my scene it would be dead slow (38 fps) and stutter (~ 1 time/second). I tried to smooth the time step and to reduce filtering quality, but the problem was still here.
In the end I just deactivate unuseful Windows services (using a recommandation list from the Internet) and rebooted, and the problem was gone. There must be one which fuck up things.
Hope it helps.
In addition to what Blueberry said and because I really like to reiterate this sad fact again and again: DO NOT USE FMOD. Unless 43.07 Hz is your frame rate of choice of course.
Also, it's kinda important when exactly to check for the system time. Eg. when you poll the time whenever you see fit, even when your GetTime() function is perfect, you get the time somewhere in the middle of the frame +/- switches to other processes, etc. Which is something you don't want.
Best practice: Get the time directly after D3DDevice::Present() (or the equivalent GL function whose name I've forgotten) and use that value for everything you do in the current frame. That specific point is the one that's most probably tied to the VSync somehow.
Also, if you're using VSync, you kind of know that the time must be somehow aligned to the frame rate. So how about querying the screen mode's refresh rate (I advise against SETTING it, see my article at the BP website for details), rounding the time you get to that refresh rate, and then also querying the sound position and nudging the time a bit forward or back as soon as the skew exceeds let's say 30 milliseconds for a few frames ;)
Best practice: Get the time directly after D3DDevice::Present() (or the equivalent GL function whose name I've forgotten) and use that value for everything you do in the current frame. That specific point is the one that's most probably tied to the VSync somehow.
Also, if you're using VSync, you kind of know that the time must be somehow aligned to the frame rate. So how about querying the screen mode's refresh rate (I advise against SETTING it, see my article at the BP website for details), rounding the time you get to that refresh rate, and then also querying the sound position and nudging the time a bit forward or back as soon as the skew exceeds let's say 30 milliseconds for a few frames ;)
This may sound silly, but have you tried increasing the process priority? Or maybe offering up a Sleep(1) per frame will appease the background service gods?
Also, apart from the multicore and speedstepping issues, QueryPerformanceCounter has the problem of giving you the actual time as the CPU sees it, whereas what you're rendering may be a variable number of frames ahead of what's currently on screen. So you can only rely on the method (or other get-current-time methods) to give you smooth animation when the time between frames is constant anyway.
I guess what you could do is read the screen's refresh rate with (there is some Win32 API function for that). The ACTUAL time between frames is always some multiple of that interval. Then it's only a matter of knowing how many frames the CPU is ahead of the GPU, and how many frames the GPU is ahead of the RAMDAC, maybe using D3DPRESENT_DONOTWAIT to make sure that the a frame rendered at time t is always shown at time t+(known no. frames). Probably not easy to do, but it would seem to me to be necessary to get perfectly smooth animation.
Also, it may be worth it to try to buffer a larger number of frames. DX9 only allows 3 backbuffers (30 on DX10, AFAIK), but you do have other options like rendering to textures. If you have say 30 frames already prepared, and you can flip them onto the screen with high enough priority, a background task stalling for a bit won't matter.
Also, apart from the multicore and speedstepping issues, QueryPerformanceCounter has the problem of giving you the actual time as the CPU sees it, whereas what you're rendering may be a variable number of frames ahead of what's currently on screen. So you can only rely on the method (or other get-current-time methods) to give you smooth animation when the time between frames is constant anyway.
I guess what you could do is read the screen's refresh rate with (there is some Win32 API function for that). The ACTUAL time between frames is always some multiple of that interval. Then it's only a matter of knowing how many frames the CPU is ahead of the GPU, and how many frames the GPU is ahead of the RAMDAC, maybe using D3DPRESENT_DONOTWAIT to make sure that the a frame rendered at time t is always shown at time t+(known no. frames). Probably not easy to do, but it would seem to me to be necessary to get perfectly smooth animation.
Also, it may be worth it to try to buffer a larger number of frames. DX9 only allows 3 backbuffers (30 on DX10, AFAIK), but you do have other options like rendering to textures. If you have say 30 frames already prepared, and you can flip them onto the screen with high enough priority, a background task stalling for a bit won't matter.
