• Advertisement

Archived

This topic is now archived and is closed to further replies.

Translucency in DirectDraw ???

This topic is 5060 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I just want to ask how if there''s any option in DirectDraw to make a certain bitmap translucent. An example of this would be a water bitmap. If your character goes in the water, the character is not fully covered but he''s still seen but with some color changes. It''s like lowering the opacity of the water bitmap. THANKS IN ADVANCE!!

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by Daerax
You must mean Alpha Blending. Here is a most brilliant implementation of an alphablending algorithim using MMX. Builds on first article, which (the first article) explains things a bit more.

Good article(s). Thanks for the link.

I was surprised at the way the author implemented the 32 bit alpha blit (MMX). He used quadwords at a time, which means the inner loop was doing 2 pixels at a time, but I would have thought it would still be more efficient to do one pixels at a time..

Here''s my implementation of a 32 bit alpha blend in MMX.

(Nasm syntax)

.AlphaPixel:
lea esi, [ esi + ecx * 4 ]
lea edi, [ edi + ecx * 4 ]
neg ecx

push edx
push ebp
push ebx
mov ebp, AlphaExpandTable
mov edx, InverseAlphaExpandTable
mov ebx, [ Blend ]
ALIGN 16
.AlphaPixelLoop:

mov eax, [ esi + ecx * 4 ]
movd MM3, [ edi + ecx * 4 ] ; MM3 = destination

movd MM2, eax ; MM2 = source
shr eax, 24

mul bl
shr eax, 8

movq MM4, [ ebp + ebx * 8 ] ; MM4 = Alpha
movq MM5, [ edx + eax * 8 ] ; MM5 = 1 - Alpha

punpcklbw MM2, MM7
punpcklbw MM3, MM7

pmullw MM2, MM4
pmullw MM3, MM5

psrlw MM2, 8
psrlw MM3, 8

paddusw MM2, MM3
inc ecx
packuswb MM2, MM7
movd [ edi + ecx * 4 - 4 ], MM2

jnz .AlphaPixelLoop

pop ebx
pop ebp
pop edx


A may try testing both routines at some point, to see which is better..

Share this post


Link to post
Share on other sites
Reading and writing two pixels at a time with the same ammount of instructions take half the cpu time in total for the same size sprite. How on earth could ding one pixel at a time be more efficient

The way those MMX instructions work take the same ammount of cycles to process all 64 bits in the register. Thus halving the total time per pixel (plus minus some overhead and playing around with data, it will take a bit longer than half the time, but still WAY faster than 1 pixel at a time)



The more I think, the more confused I get.
The best 2D game developer site out there!

Share this post


Link to post
Share on other sites
quote:
Original post by Bad Maniac
Reading and writing two pixels at a time with the same ammount of instructions take half the cpu time in total for the same size sprite. How on earth could ding one pixel at a time be more efficient

The way those MMX instructions work take the same ammount of cycles to process all 64 bits in the register. Thus halving the total time per pixel (plus minus some overhead and playing around with data, it will take a bit longer than half the time, but still WAY faster than 1 pixel at a time)



The more I think, the more confused I get.
The best 2D game developer site out there!

The code in the article uses 43 instructions for 2 pixels. The code above uses 19 instructions for 1 pixel. The code above also avoids unaligned reads, which incur a penalty.

Share this post


Link to post
Share on other sites

  • Advertisement