[Scummvm-devel] Bitdepth/pixel format API concerns

RafaƂ Rzepecki divided.mind at gmail.com
Sun Jun 14 18:33:15 CEST 2009


On Sun, Jun 14, 2009 at 6:06 PM, Kostas Nakos<knakos at phys.uoa.gr> wrote:
> Hello,
>
> On Sun, 14 Jun 2009 17:18:10 +0200
> Rafa__ Rzepecki <divided.mind at gmail.com> wrote:
>> This boils down to 522 vs. 573 FPS for swizzling vs. palette lookup,
>> respectively. Hardly a lifesaver, and that's for the most simple code
>> there is, ie. replacing outcolor = palette[incolor] with outcolor =
>> (incolor >> 10) | ((incolor & 0x3e0) << 1) | ((incolor & 0x1f) << 11);
>> this means platform-specific hacks (or, heck, even compiler
>> optimizations, above was with -O0) could easily snip away the
>> difference.
>
> While I have no experimental data to support this, I strongly believe
> that performing 4 shift ops, 3 and ops and 2 or ops per pixel is far
> from efficient, even taking into account the data cache thrashing of a
> color LUT. And gfx usually accounts for the bulk of computational power
> a gfx app requires. I'd hate to see less capable devices slow down to a
> crawl, since scummvm tries to be as lean as possible to help ports.

You're right, I was wrong and I stand corrected. Here is the data from
my G1 (HTC Dream), which is ARM-based:
# time ./swizzle 100
Running 100 iterations of swizzling RGB555->BGR565 for 640x480 fullscreen
real    0m 6.84s
user    0m 6.74s
sys     0m 0.01s
# time ./palette 100
Running 100 iterations of palette-lookup conversion for 640x480 fullscreen
real    0m 3.46s
user    0m 3.41s
sys     0m 0.02s

which is 15 FPS vs. 30 FPS, a notable, and user-noticeable difference.
Though I'm sure hand-crafted ASM could bring that to 25 FPS.

ps. I apologize Kostas for him getting this message twice, but I
replied to himself only by accident.




More information about the Scummvm-devel mailing list