[Scummvm-devel] Bitdepth/pixel format API concerns

[Johannes Schickel]

Rafał Rzepecki wrote:
> 2009/6/14 Johannes Schickel <lordhoto at gmail.com>:
>   
>> Well we are not talking about these problems for high end hardware though.
>> We still have to support some ports with processors from 200-500MHz. (mostly
>> talking about WinCE on ARM here)
>>     
>
> I understand, but the relative difference is unlikely to change. Plus
> it's another argument for the backend to do the conversion: it can
> easily utilize ASM conversion code or even hardware support, should it
> prove to be necessary.
>
>   

Well it's not exactly an ultimate argument for the backend doing the 
conversion. Of course if the game would require to do the conversion 
every time it copies data to the real screen, the backend might have a 
more sophisticated/faster approach for conversion due to more knowledge 
about the hardware run on.

On the other hand if the engine is able to do one conversion for 
multiple display instances it might be still faster overall to do that 
engine wise. An example might be actor drawing here, the engine might 
load the graphics data into memory once, doing the conversion there and 
then be able to display the data without any need to conversion later on 
(neither engine nor backend wise).

I made up some simple test as you did for the latter case. Here my 
results of your RGB555->RGB565 conversion on every screen update:

$ time ./test2 10000
Running 10000 iterations of swizzling RGB555->BGR565 for 640x480 fullscreen

real    0m17.619s
user    0m17.614s
sys     0m0.001s

And here for my simple before hand conversion:

$ time ./test1 10000
Running 10000 iterations of beforehand conversion RGB555->BGR565 for 
640x480 fullscreen

real    0m0.615s
user    0m0.610s
sys     0m0.004s

That looks a bit different now ;-). (Of course my system might cache a 
bit in that because of that memcpy call).

Both compiled via -O0 btw. Here's the source to my test1 program: 
http://pastebin.com/m48b6e75c

// Johannes