[Scummvm-devel] Bitdepth/pixel format API concerns

[Johannes Schickel]

Johannes Schickel wrote:
> And last but not least, if the backend needs to pass data in a 
> different endianness, byte swapping would be possible aye. But only if 
> the format the engine uses and the one the backend uses is exactly the 
> same! And even there it would be ugly to let all engines worry about 
> such issues. PSP3 and XBox360 are fast enough to do that backend wise 
> anyway, thus no need to hack in stuff like that.

Slight addition, if the engine is able to create any format, it's pretty 
trivial for it to create the correct data anyway. For example: ARGB8888 
in native endianness would be BGRA8888 in inverted endianness. So all 
the backend needs to do there is to provide the correctly setup 
PixelFormat struct. Of course this only works for 8 bits per color 
component based modes. (4 bits per color component might work too)

You can pretty easily see that with the ARGB8888 mode:

AAAAAAAA RRRRRRRR GGGGGGGG BBBBBBBB in one endianness would be:
BBBBBBBB GGGGGGGG RRRRRRRR AAAAAAAA in the other one.

Easy to setup via PixelFormat, just swap A, B and R, G shift values.

While for a ARGB1555 mode it would be like this:

ARRRRRGG GGGBBBBB in one endianess would be:
GGGBBBBB ARRRRRGG in the other one.

The latter one is something you can't setup via PixelFormat. Thus you 
can't easily create that mode on the fly.

Anyway for which backend we support do we need that swapped endian order 
anyway? None? I never heard of that at least... and the GUI works fine 
with all backends so far, thus probably it always worked with native 
endianness.

// Johannes