Pixel format conversion

I’m in the process of porting my game (http://NiL.sourceforge.net) from PTC to
SDL, it seems pretty straight forward, so congrats on a nice API, but I’m having
some problems with performance:

Using PTC I get 9.5 fps and with SDL I’m lucky to get 7, this is running in a
window under X, so that explains the poor frame rate in the first place, but
those 2.5 fps disappear somewhere in SDL so I’m out looking for a fix for those
frames.

The game uses 32bit for everything internally, but uses the graphics lib to
convert to the display depth at runtime, so I suspect that the performance hit
comes from the conversion process.

I don’t want to convert my internal graphics to 16 bit as that would slow down
all my work with the pixels.

I wonder if I’d be better off using Hermes to convert the pixel format to the
actual screenformat before handing over the pixels to SDL?

In short: What tricks should be applied to update a 16 bit display with 32 bit
graphics quickly?

Flemming Frandsen wrote:

Using PTC I get 9.5 fps and with SDL I’m lucky to get 7, this is running in a
window under X, so that explains the poor frame rate in the first place, but
those 2.5 fps disappear somewhere in SDL so I’m out looking for a fix for those
frames.

AFAIK PTC uses DGA, right? Never played with it, but that might be a
reason. If not then it seems that you are on a lucky machine where the
Hermes asm converters are faster - usually that isn’t noticeable if
don’t do ‘only conversion’. Well, I should time it some time…

I wonder if I’d be better off using Hermes to convert the pixel format to the
actual screenformat before handing over the pixels to SDL?

Knowing the internals of Hermes all to well I doubt that the missing 2.5
fps are SDL converters being slower. But if you want to verify it, check
out the new 1.3.0 version at clanlib.org :)–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

I’m in the process of porting my game (http://NiL.sourceforge.net) from PTC to
SDL, it seems pretty straight forward, so congrats on a nice API, but I’m having
some problems with performance:

Using PTC I get 9.5 fps and with SDL I’m lucky to get 7, this is running in a
window under X, so that explains the poor frame rate in the first place, but
those 2.5 fps disappear somewhere in SDL so I’m out looking for a fix for those
frames.

I benchmarked PTC and SDL about a year ago and they were roughly the same
speed. If you send me your original app and the SDL app, I’ll take a quick
look at it for you.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Sam Lantinga wrote:

I benchmarked PTC and SDL about a year ago and they were roughly the
same speed. If you send me your original app and the SDL app, I’ll take
a quick look at it for you.

I’m pretty much going to accept the performance hit for all the goodies that SDL
has to offer.

If you (or anyone else for that matter) have a few minutes to spare you can
build for either PTC or SDL by flipping the define in line #29 of nil_client.cpp

The source is in CVS at sourceforge, so you can do a checkout with:
cvs -d:pserver:anonymous at cvs.NiL.sourceforge.net:/cvsroot/NiL login
cvs -z3 -d:pserver:anonymous at cvs.NiL.sourceforge.net:/cvsroot/NiL co nil

There are detailed build instructions in nil/docs/NiL-HOWTO.txt
The site for NiL is: http://NiL.sourceforge.net

Anyway, exelent work, keep it up:)

I’m in the process of porting my game (http://NiL.sourceforge.net) from PTC to
SDL, it seems pretty straight forward, so congrats on a nice API, but I’m having
some problems with performance:

Using PTC I get 9.5 fps and with SDL I’m lucky to get 7, this is running in a
window under X, so that explains the poor frame rate in the first place, but
those 2.5 fps disappear somewhere in SDL so I’m out looking for a fix for those
frames.

Interesting, I’m getting similar results, and SDL is using an assembly
blit routine from Hermes.

Investigating…

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Sam Lantinga wrote:

Interesting, I’m getting similar results, and SDL is using an assembly
blit routine from Hermes.

Maybe Hermes uses another one :wink:

Investigating…

how about a little benchmarking - if you write the SDL part I will write
the Hermes benchmarking code :slight_smile:

16 -> 15
15 -> 16

16 -> 32
32 -> 16

16 -> 24
24 -> 16

15 -> 24
24 -> 15

32 -> 24
24 -> 32–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right

how about a little benchmarking - if you write the SDL part I will write
the Hermes benchmarking code :slight_smile:

I don’t have time at the moment (working on Heavy Gear 2)

Maybe some other time?
Feel free to write the tests, anybody. :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

The mystery is solved!

I’m in the process of porting my game (http://NiL.sourceforge.net) from PTC to
SDL, it seems pretty straight forward, so congrats on a nice API, but I’m having
some problems with performance:

Using PTC I get 9.5 fps and with SDL I’m lucky to get 7, this is running in a
window under X, so that explains the poor frame rate in the first place, but
those 2.5 fps disappear somewhere in SDL so I’m out looking for a fix for those
frames.

I tested your application on my system, and got similar results.
I did a little research, and found that SDL was using its built-in optimized
C blitter, and PTC was using a new PII MMX optimized assembly blitter from
Hermes.

The latest CVS snapshot contains the new PII optimized blitters! :slight_smile:

You can compare the performance of two PTC demo applications using
native PTC and using SDL via a mini-PTC emulation:

http://www.devolution.com/~slouken/SDL/projects/PTC/

Enjoy!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec