Well, is this hardware dependent? What is the color format used? I supposed it was AARRGGBB, but looks like I'm wrong..?
(A=alpha, R=red, G=green, B=blue)
I thought it was RGBA for nearly all hardware? Still, if you're editing pixels that way, you'e probably breaking some big "DON'T DO"'s of the library. I've only seen bad stuff about manually manipulating pixels by RGB values, sadly.
Of course it's hardware dependent.
The format varies per video card/hardware. There are DirectX calls which can get you the ordering info.
thefox wrote:
Of course it's hardware dependent.
Oh? Pardon my ignorance.
Are there best practices for using this ordering info in an inner loop that decodes, renders, or transforms image data, especially considering the dearth of registers on x86? Or is all such decoding, rendering, or transforming supposed to take place in a shader now?
One thing I forgot to mention. I believe there's a confusion regarding the backbuffer (a bitmap) and the screen (the hardware itself). So, I don't see any visible distortions in the PPU output while manipulating pixels in the backbuffer; the data transfer to the screen is done by blit(), and yes, the way how it does isn't interesting to me, since the library (Allegro) handles it.
What handles it in Allegro is makecol(), so long as your back buffer doesn't use indexed color, and a function call per pixel is slow in an inner loop.