Bitwise help!!!

[Digby]

Now that I think of it, if you're doing alpha blending correctly it won't overflow anyway.  Here's the typical alpha blending equation:<br><br>sC = source color (sprite)<br>dC = dest color (frame buffer)<br>a = alpha blending value<br><br>NB: assumes color and alpha are in the range 0.0..1.0.<br><br>dC = (sC * a) + (dC * (1 - a))<br><br>How is this addition going to overflow?<br><br>

[Malmer]

if you do alpha like that it will be incredibly slow (floats). no, it would be insanely slow. Besides getting the source pixel color in this case requires you to calculate the "real" color since in the source image it is faded out to black. So I have to use the alpha to figure out the real value, then I have to draw the pixel over using an alpha value. Now I don't do that process because that would be slow with many multiplications (SLOW) and maybe some divisions (SLOWER). So instead I managed to isolate a pretty nice formula using just bitshifts and one multiplication. The thing itself takes litterarly no performance if it wasn't for that it in rare cases can overflow. Why do you think Ag is the first PPC game with alpha blended sprites (am I right here?)<br><br>As for the technical name of this type of alpha blending I think it is called additive alpha blending.<br><br>// Fredrik<br>

[Malmer]

Actually...been testing some...and it isn't the method itself that causes it. What is causing it is the fact that images containing the sprite and the alpha channel aren't truecolor but are palletized making the color of certain areas of them to be less exact compared with the alpha.<br><br>Either way, I think I've found a way to fix these issues quite easily...I'll get back to you...So hopefully I can remove the conditionals alltogether. Hurray!

[Malmer]

HAHA! I fixed it! Now we just saved three if-statements per transparent pixel! Hurray! Hurray!<br>

[Dan East]

Quake allocates a minumum of 5.57 MB off the heap at startup. Actually it will allocate all the program memory available. Plus there's a few other chunks taken off the heap (for particles, etc). I think it needs close to a megabyte heap as well. The SH3 devices needed a larger heap for some reason (must need data aligned at larger intervals).<br><br>Dan East

[Digby]

Glad you got it working!<br><br>The only reason I expressed the equation using floats was so that you and others could understand it.  No one would be using floating point in an actual alpha blit routine.  <br><br>If it were me, I'd probably use premultiplied alpha in my source image and save the inverse alpha (here expressed with an 8-bit value) rather than the actual alpha, then the pixel calculation looks like:<br><br>dC = sC + (iA*dC)>>8<br><br>I'd measure the performance of this versus using a lookup table to perform the multiplication and shift.<br><br>I'm curious as to why you're using palettized sprites instead of storing them in the format native to the display?<br><br>It's good to see that you guys are in the optimization phase of the project.  You must be in the home stretch now.<br><br>

[Malmer]

I could quite easily change to premultiplied alpha. The formula I have is not very far from the one you have, but if I changed to premultiplied alpha I would have to remake all unit gfx preparations (ouch!) and john would have to rerender it all. Besides, I don't think all rendering packages out there support premultiplied alpha, so for the mod-ing community I think it is best to keep it the way it is.<br><br>Or maybe I could make it an option on each sprite...hmm...<br><br>-f

[Digby]

You could perform the premultiply and alpha inversion when the image is loaded.<br><br>

[Refractor]

[Dan East]

[Phantom]

[Kzinti]

[Phantom]

[Digby]

[refractor]