   speedy 8-bit transparency with DirectDraw?
  I am creating a game which uses 8-bit graphics and DirectDraw7.  I am trying to implement fast transparencies, but I''m not having much luck.  Basically, what I do now is create a transparency table at the start for three different levels of transparency (256*256*3).  Then, if I want to draw a sprite onto my back surface (or primary..same thing) I go through the surface pixel by pixel (the surface has my background already on it obviously) and look up the appropriate transparent colour to place there.  This is slower than I thought it would be.  Yes, I have to do a look up for every pixel that I am placing, but the frame-rate drop is dramatic.  I have tried to use some pointer tricks, but I think I am missing the bottleneck of this process.  Does it have something to do with me unlocking the back surface and extracting/writing each pixel that I need to place?  Would it be faster if I did my blitting to a temporary surface and then used a ddraw blt?  I will try this of course and continue to play around with it, but any insight would help.Abs
  Are you trying to do alpha blending?DDraw allows for one transparent color per surface and you don''t have to do any special functions to use it.  If you need more than one per surface...why?BenThe Rabbithole;  You aren''t trying to lock/unlock the surface for EVERY pixel are you?Another bottleneck could be if your backbuffer is in video memory, transfering video->system memory is REALLY slow other than that... I can''t think of anything.-Nekosion;  Hmm I wasn''t aware of the transparent colour in DDraw.  I''ll have to look up that feature although I doubt the SDK docs will help very much.  I''ll see what I can find though.Like I said, this is 8-bit transparency so I hand coded the alpha blending and stored the indicies in a table (only way to do it really).  Maybe what you guys are talking about applies to higher colour modes only.  This is probably the case unfortunately.As for unlocking/locking the surface.  I only unlock it once at the start of the blt.  If I unlocked it and locked it during every pixel operation then I would expect about 1 fps.    Yes, All of my surfaces are in video memory.  With DDraw your primary and back surfaces are always in video memory since you are going to use chain flipping for buffering.  Maybe if I did the back buffering manually instead and kept it in system memory then I could achieve better results.  It really wouldn''t be difficult to replace my Flips with Blts.  I think you are right though.  I think the slow down has to do with all of this video memory access.  I guess I''m just going to have to experiment.Abs  ;  There is a way to get the backbuffer into system memory via a flag... at least I thought that there was.Hmm, Try creating a surface in system memory then using it and blitting it to the video surface and flipping. Would be slower than just having the surface in system memory, but SHOULD be faster than it is now.Nekosion;  The problem is simple,we also had it at the begginig of our full ASM 2D game just take care NOT to READ from video memory ! this will slow you extreeme ...instead do all operations in a system memory buffer THEN blit the result on the back buffer (in video memory) then FLIP back and primary buffers...this will do it...speed optimizations are required for software alpha blending (in ASM  hehe) but is will work decently esp in 8 bits...we (full ASM) can do it in 16 bits with little trouble ...Bogdanwww.hostileencounter.com