Have you tried monitoring page faults?
Are you writing to a log file?
/Niels
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Have you tried monitoring page faults?
Are you writing to a log file?
/Niels
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
Do you see the same behaviour in both debug and release builds?
/Niels
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).]
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.x += box.sx * timeDelta;<BR> box.y += box.sy * timeDelta;<BR> <BR> if (box.x > (WIDTH - 80)) {<BR> box.x = WIDTH - 80;<BR> box.sx = -box.sx;<BR> }<P> if (box.x < 0) {<BR> box.x = 0;<BR> box.sx = -box.sx;<BR> }<P> if (box.y > (HEIGHT - 80)) {<BR> box.y = HEIGHT - 80;<BR> box.sy = -box.sy;<BR> }<P> if (box.y < 0) {<BR> box.y = 0;<BR> box.sy = -box.sy;<BR> }<P> myRect.left = round(box.x);<BR> myRect.top = round(box.y);<BR> myRect.right = myRect.left + 80;<BR> myRect.bottom = myRect.top + 80;<P> memset(&bltFX, 0, sizeof(bltFX));<BR> bltFX.dwSize = sizeof(bltFX);<BR> bltFX.dwFillPixel = box.color;<P> Target->Blt(&myRect, Null, Null, DDBLT_COLORFILL | DDBLT_WAIT, &bltFX);<BR> }<P> double endDraw = GameCore->Time()->Delta(false);<P> double beginFlip = GameCore->Time()->Delta(false);<BR> Primary->Flip(Null, DDFLIP_WAIT);<BR> double endFlip = GameCore->Time()->Delta(false);<P> totalTime = endFlip - beginDraw;<P> GameCore->System()->Message(ISYSMSG_DEBUG, "Time in drawing code: %.9f Time in flip: %.9f Total time: %.9f", endDraw - beginDraw, endFlip - beginFlip, totalTime);<BR></pre><HR></BLOCKQUOTE><P>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.<P>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 <IMG SRC="http://www.gamedev.net/community/forums/ubb/frown.gif"><P>- Splat
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
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
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
Jerry,