I was reading a few books on DirectX and some older books on DOS games and this question suddenly popped in my head: Which transparent bitblt''ing method is faster? There are 2 main styles of transparent bitblt''ing: Style 1: Blt() using the color key capabilities of DirectDraw. Style 2: Blt() using a monochrome mask and doing the standard AND/OR blts. (2 different blts). I''m thinking that the first method is faster since there is only 1 function call. However, AND/OR blts don''t have to worry about color keys and thus should general run faster since there shouldn''t be and comparisons to take up the extra CPU cycle. I''m going to try it out and find out for myself, but I was just wondering if anyone else has tried this. Dino M. Gambone
Good judgement is gained through experience. Experience, however, is gained through bad judgement.

I don''t know anything about DirectX, but the style 2 you mentioned is very fast. If you do it in asm, it will only take 2 extra instructions than solid blitting, a cmp and a jump (a few more if you want to support all color resolutions), and maybe another cmp and jump if you want one blit routine to be able to blit both solid and transparant bitmaps.

I don''t know if style 2 is faster than style 1, but style 2 is fast.

Arjan

-------------------------
-Programmers don't byte, they nibble a bit.
Unknown Person
-------------------------

How about RLE sprites? I have never actually compared the
speed difference but for large sprites it would seem better.
I remember when I used to look at the cockpit overlay in Wing
Commander and wondered how the hell they did it. The sprite
was massive. Turned out they used RLE. No compares just the
actual data that''s going to end up on the screen.

I am not sure which one is actually faster, but I know the color key method is generally much easier, mostly from the artists perspective. Also, with color keying, you dont have to load 2 images into memory for every actual image (the image + the mask). Thus using the color key should take up less memory space.

As for the actual speed between the 2, I think the color key is faster because that is what almost every game uses today. I havent seen color keys used in some time. Even civ 2 used color keying, and I am also using it and I have found it to fast enough that I can get 60+ frames per second.

Possibility

>using it and I have found it to fast enough that I can get 60+
>frames per second.

60+ fps for what? Please, give more info on that? How big is your screen? 8-, 16 or even 32-bits? And what kind of computer do you have?

I use color keys also. I have never tried masking and i don''t think i ever will because my artist is already complaining
about doing isometric tiles, and i don''t want to bother him
with more details.

I think most video cards convert colour-keys to a mask internally, since they rarely seem to support more than 1 colour key per image. But they are certainly easier to work with for most people. Either way, I expect more people will be moving to using the alpha channel soon, now that DirectDraw and Direct3D are merging, which might change the way people work.

I have a Pentium 200Mhz w/ 32 megs ram and Voodoo3 2000 (which has 16megs video ram). I have my game at 1024x768x16bit resolution and its a hexagonal tile based game, the game is not just an engine but already a full game with units, cities, productions, fog of war, ect... and everything is re-calculated and re-rendered each frame and I still get 60fps with color keying.

Possibility

in a pure software solution, there is no telling.

with bitmasking, for each pixel (or group of pixels), you need the following operations

MOV from the destination pixel map
AND with a value from the bitmask pixel map
OR with the source pixel map
MOV back to the destination pixel map

with a single transparent color (assuming the transparent color is zero)

MOV from the source pixel map
JZ to the next pixel
MOV to the destination pixel map

both of these methods have two MOV, one from mem to reg, the other from reg to mem. the only question is if ANDing with a memory location and then ORing with a memory location takes more or less time that a JZ. i''m thinking that the JZ should win

however, that''s not the only consideration. in bitmasking, we can use 32 bits for each copy, which means that we can push 1, 2, or 4 pixels at a time depending on our BPP. with the transparent color, we can only push one pixel at a time, and to use the 32 bits effectively, we have to be in 32 bit mode. to use in other bpp modes, we''d have to modify the code.

so, as with all things, there is no "better" or "best" way to do something. it all depends on what you are doing, and how you go about solving the problem.

quote: Original post by TANSTAAFL

in a pure software solution, there is no telling.

with bitmasking, for each pixel (or group of pixels), you need the following operations

MOV from the destination pixel map
AND with a value from the bitmask pixel map
OR with the source pixel map
MOV back to the destination pixel map

with a single transparent color (assuming the transparent color is zero)

MOV from the source pixel map
JZ to the next pixel
MOV to the destination pixel map

both of these methods have two MOV, one from mem to reg, the other from reg to mem. the only question is if ANDing with a memory location and then ORing with a memory location takes more or less time that a JZ. i''m thinking that the JZ should win

however, that''s not the only consideration. in bitmasking, we can use 32 bits for each copy, which means that we can push 1, 2, or 4 pixels at a time depending on our BPP. with the transparent color, we can only push one pixel at a time, and to use the 32 bits effectively, we have to be in 32 bit mode. to use in other bpp modes, we''d have to modify the code.

so, as with all things, there is no "better" or "best" way to do something. it all depends on what you are doing, and how you go about solving the problem.

Now that is a post!

Dino M. Gambone

Good judgement is gained through experience. Experience, however, is gained through bad judgement.