Hi, I am looking for a quick way to clear (colour black whatever) the surface I am using, basically, so I can do animation. This is what I am using to do this (it doesnt work, hence this post) /* START */ if(surface->Lock(NULL,&surf_desc, DDLOCK_SURFACEMEMORYPTR / DDLOCK_WAIT / DDLOCK_NOSYSLOCK, NULL)) { surfacememory = (BYTE *)surf_desc.lpSurface; long count = sizeof(surfacememory)/4; _asm{ mov edi,[surfacememory] mov ecx,count mov eax,00000000h rep stosd } surface->Unlock(NULL); } /* END */ thats is, but when I try this, it dont work, it just returns me to the MSVC++6 compiler, I dont know why, can anyone perhaps solve this little problem ? would be very grateful, thanks

hi,
no, it''s not fast at all, not in my experience, when I am blitting 72 sprites (in a space invaders formation) to the backbuffer and then one player sprite at the bottom, if I dont redraw the screen, the obvious happens, it just goes all funky.

if I use blitfx, then what happens, is that I miss the vsync I am thinking, cause only the bottom half of the invaders are drawn, if you like, I can send you an exe of what happens when you use the blitfx, with code.

just gimme email address and I''ll send ya

I think the blitfx is very slow, cause it''s just not getting the performance that I want. I have heard that asm would be faster clearing the screen, but I would like to know if anyone else has a better method which is soo fast they cannot believe it let me know

The calling function:

case GAMEPROCESS:
if(ClearSurface(1)){
if(DrawSprites(1,sdl,NULL)){
if(MoveInvaders(sptrs->SInvaders,sptrs->EInvaders)){
if(FlipChain())
{
DecodeJoystick();
DecodeKeyboard();
return true;
}else Msg(NULL, "Error: ProcessFrame() -> FlipChain() returned false");
}else Msg(NULL, "Error: ProcessFrame() -> MoveInvaders() returned false");
}else Msg(NULL, "Error: ProcessFrame() -> DrawSprites() returned false");
}else Msg(NULL, "Error: ClearSurface() -> ClearSurface() returned false");

The function in question:

int ClearSurface(int surface_index)
{
IDirectDrawSurface4 *surface = SurfacePointer(index);
unsigned short *surfacememory = 0;

DDSURFACEDESC2 surf_desc;
memset(&surf_desc,0,sizeof(surf_desc));

surf_desc.dwSize = sizeof(surf_desc);

if(surface->Lock(NULL,&surf_desc, DDLOCK_SURFACEMEMORYPTR / DDLOCK_WAIT / DDLOCK_NOSYSLOCK, NULL))
{
surfacememory = (unsigned short *)surf_desc.lpSurface;
long count = surf_desc.lPitch * 600;

_asm
{
cld
mov edi,surfacememory
mov ecx,count
mov eax,00000000h
rep stosd
}
surface->Unlock(NULL);
}
return 1;
}

The Error returned:

"Access to this surface is being refused because the surface is already locked by another thread"

suggestions anyone ?

grr, sorry about the indenting didnt work properly, but I am sure that you can read it

so, as you see, I have incorportated all the said changes and now, it doesnt crash, just returns that error, which is puzzling.....

perhaps I will clear the backbuffer and draw to the primary, therefore, I am not clashing with surface and access to them...but, perhaps, my next post

thanks..

kosh

ok, no, it doesnt work, if I clear surface 1 and draw to surface 0

primary = 0;
back = 1;

then I just get a nicely drawn screen, but the application locks, perhaps the other way around....hang on a tic....

NOPE !!! my system locks up if I try to clear surface 0 and draw to surface 1, so that doesnt work either.

any help ?

kosh

I''ve said this before, and I''ll say it again - Lock/Unlock are horrendously slow on nVidia chips after the RIVA128 - ie TNT, (Ultra) TNT 2, and GeForce 256.

So it doesn''t matter that the clear is fast, because you lose so much time directly around it.

Blt with colorfill set, on the other hand, is basically instantaneous on my GeForce, probably because it''s hardware accelerated.

So maybe it''d best, thinking about it, to do some profiling at startup, and pick the quicker of the two methods.

Strangely, I had the "only seeing half what I draw" when using a slow C iterative loop pair (which worked well on my old Riva128).

You should clear the backbuffer, flip, then clear the backbuffer again, so that both front and back surfaces are clear.

TheTwistedOne
http://www.angrycake.com

Oh, and for the record, colorfill blt is also quick on an s3 Trio64+, a 2MB Matrox Mystique, and another card that I don''t know the name of.

This is from basic testing that some of my friends have done for me.

To the problem in hand - I assume that either Lock or Unlock returned the error?

I don''t really know anything about asm (other than very basic 68K from uni , but I can''t see how that breaks things, unless you''re writing to the wrong bit of memory...

If Lock returns the error, I don''t have a clue... if Unlock returns that error, Lock probably didn''t succeed...


TheTwistedOne
http://www.angrycake.com