Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 

 Home / General Programming / Slow alpha blending Account Manager
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Greger

August 01, 1999, 05:35 PM

Hi!

I'm writing a breakout clone that's pretty nice. A week ago I added alphablending
and since then the game has been terribly slow. The game uses DirectX and runs in
640x480 and 16bpp.
I use the Alpha blending code that was presented with the tutorial on gamedev.net
and I only use alphablending on few bricks, and the framerate drops from 160 to 30-40.
Not very good.

Now I wonder if there is a faster way of doing alphablending (without using 3d hardware)?

 
Justin Wilder

August 05, 1999, 04:50 AM

Alpha blending, by its very nature, must be slow if not implemented in hardware. Whereas a normal blit requires one read and one write for every pixel, an alpha-blended blit requires a read from both surfaces, the blend, and the write. But the blend itself is not really what slows it down, it is the extra read.
Just about every 2d card out there today supports accelerated blits from one section of video memory to another. When you alpha blend in hardware that doesn't support the function, any block-blit acceleration gain the video card gives you will be *completely* negated. In fact, not only do you lose accelerated blits, you also have the enormous overhead of reading bits from video memory (which is never a good thing to do).
Actually, reads from video memory are so prohibitively slow that you may as well not put your surfaces in video memory at all. Instead, the wise thing to do would be to use system memory surfaces for both your sprites and your back-buffer, and just blit the entire back buffer to video memory before every flip. This avoids the video read overhead, but adds the overhead of copying the large off-screen buffer to video memory for every frame and disallows any form of hardware acceleration.
Either solution is hardly a good solution at all. Exactly how many 2d games do you remember seeing translucency in? None, until very recently (notably, Starcraft -- it doesn't even use alpha, though, it uses 8-bit translucency maps). There's a good reason for this: there simply hasn't been enough cycles to spare until now (and not even now, really). Sorry to be the bearer of bad news...

Justin

Greger wrote:
>>Hi!
>>
>>I'm writing a breakout clone that's pretty nice. A week ago I added alphablending
>>and since then the game has been terribly slow. The game uses DirectX and runs in
>>640x480 and 16bpp.
>>I use the Alpha blending code that was presented with the tutorial on gamedev.net
>>and I only use alphablending on few bricks, and the framerate drops from 160 to 30-40.
>>Not very good.
>>
>>Now I wonder if there is a faster way of doing alphablending (without using 3d hardware)?

 
Greger

August 05, 1999, 05:34 PM

That wasn't any bad news, well maybe a little, but I had all my surfaces in videomemory
and when I changed it the FPS increase with 70 (I don't full rely on my FPS counter though).
Why does DirectDraw create surfaces in videomemory if the reads are so slow? That's kinda stupid.

You're right in that not many 2d games use alpha blending, but dxball2 does, and that's the game I'm trying to beat. I've even coded a little raytracer so the user can create the look of the ball before they start. Maybe a little overkill, but it's cool.

Greetings Tobias

 
Tim lewis

August 18, 1999, 05:28 AM

if you're willing to restrict yourself to 50/50 blending then yes there is!

here's the code to do it, this is 32bit but it works in 16bit too.
the two 32bit colours to blend are col1 and col2

col1 &=(0x00FEFEFE);
col1 >>=1;
col2 &=(0x00FEFEFE);
col2 >>=2;
col1+=col2;

That code works by creating a 'bit gap' between each element of the rgb dword and then shifting it right one (halving it). Because the bitgap is there, the colours won't bleed into
each other and by the time it's done no colour will be greater than 127. After you've halved
their intensities, you can just add them as normal.

Hope that helps,

Tim Lewis.


 
This thread contains 4 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.