I downloaded the ddraw code from the tutorial: http://spiff.tripnet.se/~iczelion/files/dc-ddraw.zip

I changed the include to the ddraw.inc that came in the zip file, and it compiled perfectly.

The screen seems to flicker and is on a win2k machine. Here is some of the source, I am thinking it might have something to do with the vertical blank wait...

INVOKE GetFocus

.IF eax == hWnd

mov , sizeof DDSURFACEDESC
mov , DDSD_PITCH

.WHILE 1
DDSINVOKE mLock, lpDDSPrimary, NULL, ADDR ddsd, DDLOCK_WAIT, NULL

.BREAK .IF eax == DD_OK

.IF eax == DDERR_SURFACELOST
DDSINVOKE Restore, lpDDSPrimary
.ELSE
FATAL "Couldn't lock surface"
.ENDIF
.ENDW

DDINVOKE WaitForVerticalBlank, lpDD, DDWAITVB_BLOCKBEGIN, NULL

call nextFrame

DDSINVOKE Unlock, lpDDSPrimary, ddsd.lpSurface

.ENDIF
.ENDIF
.ENDW

DDINVOKE RestoreDisplayMode, lpDD
.IF eax != DD_OK
FATAL "Couldn't restore displaymode"
.ENDIF

thnx for any help provided.
Posted on 2002-04-23 01:47:08 by drarem
Hi !

The call of WaitVB is correct and I do not really know the problem but two suggestions I have:


1) Why are you locking the primary surface ? This might be a problem because before sending the VBBlockBegin-Signal DirectX may sets the screen to display during this frame. And if it is locked no changes must not be done.

2) Do you have (enough) backbuffers created ?


Greetings, Caleb
Posted on 2002-04-23 17:57:39 by Caleb
As long as you can redraw the whole screen faster than a screen
refresh, locking primary surface and waiting for VB should be fine.
I still prefer backbuffering though, on some cards I've seen odd behaviour,
like the scan update being frozen at the middle of the screen. Ie,
the screen update is done fast enough, but the electron cannon
is at the middle of the screen when WaitForVerticalBlank returns.
Posted on 2002-04-23 20:34:14 by f0dder