Re: [AD] Component ordering and mixing color depths

[Robert Jr Ohannessian <rohannessian@xxxxxxxxxx>]

Eric Botcazou wrote:
> If I understand correctly, RGBA sprites are currently never drawn directly to 
> bitmaps, i.e without applying a blending formula for each pixel, so your 
> reasoning is that swapping the components in the process would be only 
> marginally slower, isn't it ?


The problem is that the RGBA ordering of a 32-bpp bitmap isn't 
predictable when you are in a 16-bpp screen mode. This means that I must 
write *two* blenders: one for RGB ordering and one for BGR ordering. The 
traditional Allegro blenders avoid this issue by using getr() (and 
family) and makecol(). FBlend, on the other hand, does not.


> Two objections:
> - I think that drawing a RGBA sprite onto a bitmap without using the alpha 
> channel (i.e with draw_sprite) ought to be supported, in which case the RGBA 
> sprite must have the same color layout as a regular 32-bit sprite.

I don't see this as being useful at all; one could simple blit into a 
16-bpp bitmap to color convert, then draw_sprite that image into the 
destination. Or are you refering to something else?


> - Can't we imagine hardware-accelerated blitting routines using the RGBA 
> format, in which case the layout of the format would likely match that of the 
> regular 32-bit format ? But you're the specialist here.

What do you mean by "regular" 32-bit format? Do you mean hw accelerated 
32->16 blitting?


--
- Robert Jr Ohannessian
http://bob.allegronetwork.com/
The peer will come and reset your connection. RUN WHILE YOU STILL CAN!



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Alleg-developers mailing list
Alleg-developers@xxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alleg-developers