Re: [AD] Component ordering and mixing color depths

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/