pouët.net

hey,

i'm wondering if someone else has come accross the same problem. assume you have a (almost) static background scene with like 100 batches and lots of triangles. your demo runs with > 100 FPS on your system. now you add a slowly moving scrollpic (semi-transparent) in the foreground. instead of scrolling smooth, it is "stuttering" somehow. means moving smooth, then it looks like severe jumping for some pixels, then it moves normally again, etc.

i use a QueryPerformanceCounter to measure my times between frames and use this time to update the scrollpicture (as with all other effects) but it seems to stutter. i also tried to use a fixed step value, same stuttering as well. so it's not the timer. (at least my observation).

any ideas? hints? suggestions? thanks

vsync.

obvious, i tried that. same result.

Use query performance counter only once, then always use the cached delta + vsync, then.

yeah, but the delta may differ over time?

does it work better in fullscreen mode?

i tried vsynch again, and a fixed timestep, it still stutters. but it's less + it looks like my fps is always dropping to 56.xFPS (from 59.x FPS) when it stutters

smash: no, same result :(

got any crap running in the background?

like, windows?

(sorry, coudn't resist)

no, i tried that. (my gfs computer has the same prob)

ok, it looks better now. what i did:

- vsynch (by app)
- fixed timestep
- perform an occlusion query over the whole scene (to make sure buffers are finished. my demo is gpu bound as hell)

i still get stuttering here and then but only once in 10 seconds or so.

i'm just not sure if this is really the way to go, or if i am just hiding the problem.

other issue: i have a fixed timestep now, but what should i do when i get below 60 FPS?

can you change the pre-render limit in your graphics card settings?
maybe it's some buffering issue.

decade old kludge once more:

float smoothtime() {
static float A, B;
float tmp = shittytime();
A += (tmp-A)*0.1;
B += (tmp-B)*0.05;
return A*2-B;
}

tune magic constants to your taste.

That is some really weird lookin' filter you got there 216!

yeah looks almost perfect now, thanks a lot

i had this same problem on blunderbuss and had to heavily smooth the frame delta to get it looking decent. very annoying.

Ah yes, the good old fullscreen-scroll-issue. Something the Amiga could pull off with three lines of AMOS, but still a massive challenge to even the best TASM hacker on the PC. :)

There is actually a lot to be said for fixed refresh rates.

BTW, isn't QueryPerformanceCounter borked on multi-core systems?

gloom: ability to scroll is inversely proportional to machine power...

Yeah, the ZX81 is shit hot at it ;-)

Humbug. You can do perfectly smooth scroll with 3 (relatively long) lines of gwbasic.
...as long as you keep scrolling the whole damn screen by integral number of pixels per frame and don't run anything stupid on the background, like emm386 or windows :)

What I do is I call QueryPerformanceFrequency each time inside the loop. Reason: Modern CPUs tend to tune their speed according to their work load. Querying the frequency each time will ensure you accurate timing values.

I have similar problems here. I will try the smoothing trick

trc_wm, if you use queryPerformanceCounter wisely it works perfect on multicore systems aswell. You need to know why it's working strange on multicores to be able to prevent it.

I usually interpolate all my values with time so i get smooth data for most effects.