Performance & symbols

SDL Development
1

Hi! I noticed that the file libSDL.a in lib.win32/x86 in SDL-0.6f
seems to lack symbol information; I can’t compile against it. I
haven’t tried out the linker’s suggestion of running ranlib on it,
though. I have no memory of having to do that on 0.6e, so there’s
definitely something strange going on.

On a completely different hand, I’ve just gotten my main game engine
up and running under SDL! Big cheers from the audience!! :slight_smile: Un-
fortunately, performance is … disappointing. I just remembered why
I used to like writing against DirectDraw. It seems Windows users
are simply destined to get better gaming experience; currently my
engine manages about 15 fps under SDL/x11, whereas the original
(straight DirectDraw/Input) version easily managed 80-90 fps. :frowning: !

Realise that I’m not blaming you for anything here. I’m just being
shaken into reality, and not quite enjoying the experience. Hmmm.
Exactly how much acceleration does SDL use under X11? I guess “zip”;
is that necessarily so? Doesn’t X provide functionalty for blitting
pixmaps or what they call it? I know that XFree86 has some support
for my video board (a Matrox Millennium)…

/Emil

2

… performance is … disappointing. I just remembered why
I used to like writing against DirectDraw. It seems Windows users
are simply destined to get better gaming experience; currently my
engine manages about 15 fps under SDL/x11, whereas the original
(straight DirectDraw/Input) version easily managed 80-90 fps. :frowning: !

Have you actually tried the engine under SDL/DirectX? You should get
similar performance to what you expect.

Nope, I haven’t because of the link problem I mentioned. But 0.6g
just flew down the line, so I’ll by trying that in a moment.

Tips for speed under SDL:

A. Set the SDL_HWSURFACE flag on SDL_SetVideoMode() – UNLESS you are
going to be directly writing to the surface pixels, in which case
most newer video cards are faster using SDL_SWSURFACE and accelerated
blits.

Done.

B. Make sure you set a high-speed video mode. SDL_GetVideoMode() is
a very useful function.

Hm… I sort of “know” that I need 640x480x8; is there any point in
“looking” for that mode? Now I just set it and let that be the end of
it.

C. Convert all your artwork to the surface format of the display surface.
If you are using SDL surfaces, use SDL_DisplayFormat() to convert them.

I always do.

B. Set the SDL_RLEACCEL flag in colorkeyed blits. This is a huge speedup
when doing colorkeying on software surfaces.

I do that, too. Can it ever cause surfaces not to be blitted by the
hardware, if they are HWSURFACEs?

C. Don’t use alpha blending every frame - it’s cool, but slow.

I never use it. Pure color keying is enough right now…

D. Update only those areas which have actually changed. Important!

Arg. That’s the one I can’t comply to. My app uses full-screen
scrolling, and thus rebuilds the entire screen from scratch every
frame. :frowning:

There is however one method of X11 setup that I don’t currently use:

XFree86 Direct Graphics Access

With this, you shove the X Server aside and directly access the display
video memory. You still don’t get hardware acceleration (last I heard)
but you get to scribble all over video memory to your heart’s content.
Unfortunately, your app requires root priviledges.

Yeah, I’ve seen some DGA programs around. It’s fairly cool, but as
you say wouldn’t gain much in raw performance. It’s nice to be able
to switch to a lower resolution, though (I generally think games gain
from being run full-screen).

/EmilOn Fri, 17 Apr 1998, Sam Lantinga wrote:

3

Can you forward that message to the list?

Done. I’m a bit sceptical about the list; I got the reply when i
subscribed to it, but I haven’t seen any traffic on it. How many
subscribers are there?

/EmilOn Fri, 17 Apr 1998, Sam Lantinga wrote:

4

… performance is … disappointing. I just remembered why
I used to like writing against DirectDraw. It seems Windows users
are simply destined to get better gaming experience; currently my
engine manages about 15 fps under SDL/x11, whereas the original
(straight DirectDraw/Input) version easily managed 80-90 fps. :frowning: !

Have you actually tried the engine under SDL/DirectX? You should get
similar performance to what you expect.

Nope, I haven’t because of the link problem I mentioned. But 0.6g
just flew down the line, so I’ll by trying that in a moment.

Tips for speed under SDL:

A. Set the SDL_HWSURFACE flag on SDL_SetVideoMode() – UNLESS you are
going to be directly writing to the surface pixels, in which case
most newer video cards are faster using SDL_SWSURFACE and accelerated
blits.

Done.

B. Make sure you set a high-speed video mode. SDL_GetVideoMode() is
a very useful function.

Hm… I sort of “know” that I need 640x480x8; is there any point in
“looking” for that mode? Now I just set it and let that be the end of
it.

Under X11, if you’re running > 8 bit, SDL can’t set the display to 8-bit,
so it’s emulated with a shadow surface. This is relatively slow.

C. Convert all your artwork to the surface format of the display surface.
If you are using SDL surfaces, use SDL_DisplayFormat() to convert them.

I always do.

B. Set the SDL_RLEACCEL flag in colorkeyed blits. This is a huge speedup
when doing colorkeying on software surfaces.

I do that, too. Can it ever cause surfaces not to be blitted by the
hardware, if they are HWSURFACEs?

Nope. If hardware acceleration is available, it’s used.

C. Don’t use alpha blending every frame - it’s cool, but slow.

I never use it. Pure color keying is enough right now…

D. Update only those areas which have actually changed. Important!

Arg. That’s the one I can’t comply to. My app uses full-screen
scrolling, and thus rebuilds the entire screen from scratch every
frame. :frowning:

That’s fine. :slight_smile:

There is however one method of X11 setup that I don’t currently use:

XFree86 Direct Graphics Access

With this, you shove the X Server aside and directly access the display
video memory. You still don’t get hardware acceleration (last I heard)
but you get to scribble all over video memory to your heart’s content.
Unfortunately, your app requires root priviledges.

Yeah, I’ve seen some DGA programs around. It’s fairly cool, but as
you say wouldn’t gain much in raw performance. It’s nice to be able
to switch to a lower resolution, though (I generally think games gain
from being run full-screen).

I will definitely support DGA, I just haven’t gotten around to it yet.

See ya!
-Sam Lantinga (slouken at devolution.com)> On Fri, 17 Apr 1998, Sam Lantinga wrote:

–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

5

B. Make sure you set a high-speed video mode. SDL_GetVideoMode() is
a very useful function.

Hm… I sort of “know” that I need 640x480x8; is there any point in
“looking” for that mode? Now I just set it and let that be the end of
it.

Under X11, if you’re running > 8 bit, SDL can’t set the display to 8-bit,
so it’s emulated with a shadow surface. This is relatively slow.

It’s interesting that you should mention that. I just notices that
my little test-app (inv) drops from a rock-solid 60-70 fps @ 8bpp
down to a tragic 14 fps @ 16 bpp. Checking the current display
depth and setting that in “my” video mode got it up to ~40 fps. :slight_smile:

D. Update only those areas which have actually changed. Important!

Arg. That’s the one I can’t comply to. My app uses full-screen
scrolling, and thus rebuilds the entire screen from scratch every
frame. :frowning:

That’s fine. :slight_smile:

One single 640x480 blit (from a larger source) achieves full-screen
scrolling pretty painlessly. Works for me.

[DGA]

I will definitely support DGA, I just haven’t gotten around to it yet.

Ah. Can’t wait for 0.6z, then. Maybe next week? :slight_smile:

/EmilOn Fri, 17 Apr 1998, Sam Lantinga wrote:

6

Under X11, if you’re running > 8 bit, SDL can’t set the display to 8-bit,
so it’s emulated with a shadow surface. This is relatively slow.

It’s interesting that you should mention that. I just notices that
my little test-app (inv) drops from a rock-solid 60-70 fps @ 8bpp
down to a tragic 14 fps @ 16 bpp. Checking the current display
depth and setting that in “my” video mode got it up to ~40 fps. :slight_smile:

That’s what SDL_GetDisplayMode() does for you – it finds the “best”
video mode that’s closest to what you want. You just set that video
mode, convert your artwork to that format, and be prepared to handle
any format of surface in your direct drawing code.

I have yet to have a fully optimized SetPixel() routine that works
for all surfaces. There are just too many variables involved to do
it the “fastest” way.

Maybe I should look into a dynamically compiled routine?

One single 640x480 blit (from a larger source) achieves full-screen
scrolling pretty painlessly. Works for me.

Your card rocks. Not everyone has as nice a video card and/or CPU.
Keep that in mind.

[DGA]

I will definitely support DGA, I just haven’t gotten around to it yet.

Ah. Can’t wait for 0.6z, then. Maybe next week? :slight_smile:

laugh I’m slowing down here, getting some “real” apps working with SDL,
before going bananas developing it. :slight_smile:
Stability time!

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/