[Scummvm-devel] Bitdepth/pixel format API concerns

[Johannes Schickel]

Filippos Karapetis wrote:
> > I guess only in the case these platforms would have too limited
> > performace otherwise. So if the engine is able to convert all data on
> > the first load to the native format, it would be better than doing a
> > conversion every copyRectToScreen call. Of course if the backend is 
> able
> > to do that conversion without any real performance loss it should be by
> > the backend.
> >
>
> Why not use the appropriate set of functions to do that depending on 
> the backend
> itself, in a similar fashion to how we handle platform endianness? 
> (like I mentioned
> in a previous e-mail). There won't be any performance loss there, as 
> each backend
> would use its own set of functions.

Because for example on some SDL platforms on one system you have ARGB on 
another maybe ABGR etc. thus we can't easily check for that on compile time.

Next you can't even easily convert ARGB1555 to BGRA5551via some byte 
swapping for example. Just take this example:

R = 0x00, G = 0x08, B = 0x00 (in [0x00, 0xFF])

Now both have an G loss of 3 thus the G value in their format would be 
0x01 (just do 0x08 shift right by 3 for that).

Now for ARGB1555 the G shift would be 5. For BGRA5551 it would be 6.

In ARGB mode it would be 0x0020. In BGRA it would be 0x0040. Byte 
swapping doesn't work here, so the conversion isn't as simple as with 
endian conversion.

Bascially you would need exactly the shift values (and maybe the loss 
values), which are provided by PixelFormat.

Next as Kirben suggest doing such color conversion would increase the 
complexity of SCUMM pretty much, thus he would rather have the backend 
doing it. (Check his last mail from today for that).

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.

The (at least Max's, _sev's (when I got their mails correctly) and mine) 
idea is currently: let the engine specify exactly the PixelFormat it 
needs and let the backend worry about conversion to its native format 
when necessary. No need for additional code in the engines, no need for 
new defines engines would need to use and no need for new 
macros/conversion functionality for the engines.

// Johannes