Archived

This topic is now archived and is closed to further replies.

Visual stutters

This topic is 6595 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Here's some stats:

578 page faults, and this is not at all linked to the run length of the demo (seems to be just in the initialization of the demo)

1 I/O write, that's to open the log file that I don't use

The screen res, bpp, or number of boxes I have on the screen seem to have no effect on the stuttering effect - it's just as annoying with one box as with 500.

I took out the GDI TextOut that was writing the fps to the screen, no effect.

The actual display loop is so simple (basically a color fill on the background and color fills for each boxes) that I really have no idea what's going on.

- Splat

Share this post


Link to post
Share on other sites
Are you using double buffer? (There he goes again ) It could be a flip() that skips an additional frame for some reason. Try using the highres counter to measure average, min and max time spend in your render loop (on drawing and flipping respectively).

Do you see the same behaviour in both debug and release builds?

/Niels

Share this post


Link to post
Share on other sites
Ok, Niels, you are a very smart and experienced person. Now, what to do!

First off, same problems with double and triple-buffering.

Anyway, it appears that the Flip() (which is DDFLIP_WAIT, for your info) is skipping a frame sometimes, as is evidenced by it's total time spiking from the normal 0.008217523 seconds to 0.021536530 seconds, which is almost 3 times as long.

I get this problem in every configuration that I've tried. I haven't had a chance to try it on a different machine, but that's next. I can only suspect drivers now, since I am running on Win2000. But it doesn't happen with any other DX or OpenGL for that matter software I have!

- Splat

[This message has been edited by Splat (edited November 21, 1999).]

Share this post


Link to post
Share on other sites
Ok, there must be something I've overlooked. Same problems on several other machines. So I've reached the last step, the one that I hate others doing but I must: I must post a chink of code:

code:

frame++;

double timeDelta = GameCore->Time()->Delta(true);

double beginDraw = GameCore->Time()->Delta(false);
HDC hdc;

fps = (4*fps + (1 / timeDelta)) / 5;

DDBLTFX bltFX;
memset(&bltFX, 0, sizeof(bltFX));
bltFX.dwSize = sizeof(bltFX);

if ((1.5*(1 / fps)) < totalTime)
bltFX.dwFillPixel = 0xffff;
else
bltFX.dwFillPixel = 0x0000;

Target->Blt(Null, Null, Null, DDBLT_COLORFILL | DDBLT_WAIT, &bltFX);

RECT myRect;
int i;
for (i = 0; i < NUMOFBOXES; i++) {
box[i].x += box[i].sx * timeDelta;
box[i].y += box[i].sy * timeDelta;

if (box[i].x > (WIDTH - 80)) {
box[i].x = WIDTH - 80;
box[i].sx = -box[i].sx;
}

if (box[i].x < 0) {
box[i].x = 0;
box[i].sx = -box[i].sx;
}

if (box[i].y > (HEIGHT - 80)) {
box[i].y = HEIGHT - 80;
box[i].sy = -box[i].sy;
}

if (box[i].y < 0) {
box[i].y = 0;
box[i].sy = -box[i].sy;
}

myRect.left = round(box[i].x);
myRect.top = round(box[i].y);
myRect.right = myRect.left + 80;
myRect.bottom = myRect.top + 80;

memset(&bltFX, 0, sizeof(bltFX));
bltFX.dwSize = sizeof(bltFX);
bltFX.dwFillPixel = box[i].color;

Target->Blt(&myRect, Null, Null, DDBLT_COLORFILL | DDBLT_WAIT, &bltFX);
}

double endDraw = GameCore->Time()->Delta(false);

double beginFlip = GameCore->Time()->Delta(false);
Primary->Flip(Null, DDFLIP_WAIT);
double endFlip = GameCore->Time()->Delta(false);

totalTime = endFlip - beginDraw;

GameCore->System()->Message(ISYSMSG_DEBUG, "Time in drawing code: %.9f Time in flip: %.9f Total time: %.9f", endDraw - beginDraw, endFlip - beginFlip, totalTime);


Just for a translation, GameCore is the GameEngine I wrote (nothing big yet), GameCore->Time()->Delta() will get the time in seconds since the last call to Delta(true). GameCore->System()->Message() will just output a message to the appropriate channel(s) ie log file, debugger, message box.

Primary is the primary surface, and target is the GetAttachedSurface() back buffer. I have code in there (near the top) to see if the total frame time last frame was out of bounds for the current average frame rate. If it was, display a white background instead of black. I get quite a few flashes

- Splat

Share this post


Link to post
Share on other sites
Just a guess here, but if you're using the DDFLIP_WAIT flag your program could occasionally be hitting the video card during the middle of a refresh and having to wait until that refresh is completed before the function returns (as a result of DDFLIP_WAIT that is).

Share this post


Link to post
Share on other sites
Forgive me if you've already ruled this out, but...

It could be that your demo is being pre-empted by another process on your computer. The disk activity might be Win2K paging out your app and loading in another.

To test this, try setting the thread priority to High or even RealTime via the Task Manager (or via an API call, but I forget the name... SetThreadPriority maybe?), and see what happens.

Mason McCuskey
Spin Studios
www.spin-studios.com

Share this post


Link to post
Share on other sites
I hate this shitty demo

Shinkage: Well, that would account for the frame skipping, but the real question is why would it miss? The drawing code and flipping code are in a very tight loop, and the drawing code takes no time. So it gets to the Flip() WAY before it is time for the next.

Mason: At RealTime priority, the are no dropped frames. Anything else and I get dropped frames.

Listen, you all have been a great help. The dropping frames is not that big a deal anymore. I'm ok with it dropping a frame or two every 10 seconds. I think that frames dropping become much less visible when I start using sprites and backgrounds, etc. because everything blends together. With bright boxes on a black background the dropped frame is easily visible.

- Splat

Share this post


Link to post
Share on other sites
This sounds very familiar to a problem I had, where I was losing 3-10+ frames of animation during my level (but only once, and at a fairly predictable time). There is no mem allocation, and no disk access during the levels, and lots of timings told me that there was nothing in my code that hicupped. I thought maybe the sound/music spooler, but I got rid of it and still had missing frames.

Finally I tried a SPY program to see what the system was doing, and there was a very suspicious msg to the 'Windows 32bit VxD message server' right before my hiccup (msg 0x505). Now I have no idea what this is, but to get rid of the hiccup I had to crank my class priority to HIGHEST and thread priority to HIGH. I'm not sure if that's the best solution, but nobody was able to give me another solution.

I'd say to check what msgs are floating around, and see if this is the same problem.

Rock

Share this post


Link to post
Share on other sites
Had a problem with permedia2 card where I thought there were sticky keys or problems with direct input7, but instead the card couldn't flip and had to wait, thus appearing to stutter. So instead of using DDFLIP_WAIT I used DDFLIP_DONOTWAIT, and it worked. Try it and let us know. Good luck.

Jerry,

Share this post


Link to post
Share on other sites
Ok, this is not a big deal, but it still bugs me. I have a nice little demo with boxes bouncing around the screen, running at the monitor refresh rate of 75 fps. However, every 4-5 secs or so (not consistant or predictable) there will be a momentary visual stutter where the boxes real quickly stop and then start again, and sometimes there is a little HD activity accompanying this.

Now, I am moving the boxes based off the time delta, so that's not the issue. I'm pretty sure that the computer is just not giving my demo enough time - but most other demos and games I've seen don't seem to have this problem.

Maybe there's an override, or some simple parameter I'm missing.

- Splat

Share this post


Link to post
Share on other sites
Umm, first off the problem was a non-problem from the beginning: I was simply overreacting to frame dropping that I had never noticed in every other DX software I had because they drew sprites that didn't show the effects of a frame skip NEARLY as much as clear bright boxes moving at a perfectly constant speed on a black background. Secondly, the DDFLIP_DONOTWAIT will not solve anything in this case. It is useful if your code is / can be arranged so that you can efficiently make use of the time waiting for the VSYNC or the blits to finish. That way, you can run real code while waiting instead of having DX enter into a wait loop for you.

- Splat

Share this post


Link to post
Share on other sites