Hi guys,
Well I was wondering if there was any difference for AGS displaying a sprite using magic pink for transparency vesus a png image using its alpha channel for transparency.
Im guessing it would be "faster" for AGS to draw the transparency with the magic pink, am I right?
If so, then does that mean for a fullscreen effect (a view with 20+ frames, 1024x768) with lots of areas that are transparent, its better to use magic pink for the transparency rather than have a huge png with the alpha channel making the transparency...right?
...or does this "not matter" since today's computers are good enough that the speed difference is negligeable...
I believe the transparent areas of image, AGS automatically makes it 'Color transparent' / pink, except for the areas that actually have color or alpha channel.
ok so the png alpha is converted into pink so a bmp you import with pink as trasnparent is the same as a png you import using its alpha...?
...meaning AGS wont draw one version "faster" than the other, right?
I doubt you'll see any difference in Direct3D mode since modern graphic cards are optimized to render thousands of alpha particles every frame. Theoretically speaking non-alpha sprites (or alpha sprites with only 100% opaque and 100% transparent pixels) should render faster since the drawing function won't need to calculate any color blending, but I don't know if there would be any noticeable difference even in DirectX 5 mode.
Alright, I just wanted to be sure I understand a bit more on how AGS processes the transparency.
Well thanks guys for your information, it helps!
Alright, so I decided to test this. Using two identical sprites at 100x100. Except one has pink and one with alpha.
I tested them each drawing them on the background surface 149,000 times in a loop.
The alpha did it in 29 seconds! The one with pink does it in 8 seconds! I ran these multiple times getting the same times.
So yes. Pink is actually much much quicker than the alpha transparency, oddly enough.
ALSO.. I noticed that there is nearly ZERO difference between doing this:
while (i<149000)
{
DrawingSurface *surface = Room.GetDrawingSurfaceForBackground();
surface.DrawImage(x, y, sprite);
surface.Release();
i++;
}
And this:
DrawingSurface *surface = Room.GetDrawingSurfaceForBackground();
while (i<149000)
{
surface.DrawImage(x, y, sprite);
i++;
}
surface.Release();
With it grabbing the drawing surface once rather than whatever cycles the while loop does. I was totally wrong.
Quote from: Ryan Timothy on Mon 11/10/2010 02:09:32So yes. Pink is actually much much quicker than the alpha transparency, oddly enough.
Interesting experiment. So when you say the sprites were identical, does that mean even the alpha sprite only had 100% opaque and 100% translucent pixels, but stored in the alpha channel rather than as colored pixels? Or did it have semi-transparent pixels?
Quote from: GarageGothic on Mon 11/10/2010 02:15:54
Interesting experiment. So when you say the sprites were identical, does that mean even the alpha sprite only had 100% opaque and 100% translucent pixels [..]
Yep.
This:
(http://www.bryvis.com/entertainment/other/agsf/test_pink.png)
VS this:
(http://www.bryvis.com/entertainment/other/agsf/test_alpha.png)
Wow, that's crazy. I realize that the drawing routines still need to examine each pixel for alpha value, so if it took twice the time I could understand, but more than three times longer? Thanks for doing the research, this is very useful information to keep in mind.
Thanks for making this test, Ryan!
Obviously though, no one here is drawing 149,000 sprites per game loop. But now we know that if we don't have any alpha channels, just use the pink instead of saving it as a transparent image.
It will definitely help keep the frame rates lower.
Wow! Its really good to know then...thanks for doing that, I was going to test that out today actually :P
Sauce-sem!
Quote from: Ryan Timothy on Mon 11/10/2010 16:19:35Obviously though, no one here is drawing 149,000 sprites per game loop.
Divide the 149,000 by the number of seconds it took, and 40fps for the average game and you'll see it translates to 128 sprites with alpha and 465 without - those number are pretty representative of how many sprites you would expect a particle system to draw per frame, so the difference in performance is far from trivial.
Taking several times longer is fairly logical since *each channel* needs to be blended with relation to the resultant alpha.
The blending function is quite a few operations when an alpha channel is involved.
Although you would expect the engine to ignore blending on pixels with 0 or 255 alpha values since no blending is needed, comparisons are very expensive and its usually quicker to do the calculation anyway rather than waste cycles doing a comparison.