OpenGL to SDL = Slower?

JF_Perusse · May 23, 2005, 4:22pm

Hi,

I'm new to SDL and I just ported one of my game, which was using OpenGL/glut

(in 2D), to SDL. Currently, my biggest problem is that the game is running way
slower than when it was with OpenGL.

I'm using this video mode : 
    m_screen = SDL_SetVideoMode(800, 600, 32, SDL_SWSURFACE);

I also tried HWSURFACE instead SWSURFACE, tried using ANYFORMAT, FULLSCREEN,

Double Buffering… But it’s always slower than my OpenGL implementation.

I verified with SDL_VideoDriverName that I was using DirectX.

Most of my textures have an alpha channel. I'm using really simple code to

blit the textures, like :
SDL_BlitSurface(pSurface, &rcSrc, pScreen, &rcDest);

Also, my textures are read from PNG files, using SDL_image library.

I replaced my display lists with surfaces that don't change.

Finally, I ported my TrueType fonts (I was using glText) with SDL_ttf. After

profiling, this part doesn’t seem slower than before. So the problem seems more
related to slow blitting…

I hope any of you will have an idea why it is slower.

Thanks a lot!

Drake_Wilson · May 23, 2005, 6:00pm

Quoth JF Perusse , on 2005-05-23 16:22:37 +0000:

Hi,
I'm new to SDL and I just ported one of my game, which was using OpenGL/glut
(in 2D), to SDL. Currently, my biggest problem is that the game is running way
slower than when it was with OpenGL.

You can use OpenGL with SDL. Just set your video mode with SDL_OPENGL,
then issue GL commands as desired.

I also tried HWSURFACE instead SWSURFACE, tried using ANYFORMAT, FULLSCREEN,
Double Buffering… But it’s always slower than my OpenGL implementation.

Having surfaces not be in the format of the display is a common culprit;
this requires converting pixel formats on blit, which is slow. You can
use SDL_DisplayFormat to get a copy of a surface that is in the format
of the current display.

Most of my textures have an alpha channel.

Software alpha blits are slow. It’s generally considered to be better
to use OpenGL for this AFAIK. I don’t exactly recall what the situation
was with alpha blitting, but last I heard there wasn’t support for
hardware acceleration for that with the SDL functions alone… ?

—> Drake Wilson

Gabriel_Gambetta · May 23, 2005, 6:04pm

I hope any of you will have an idea why it is slower.

Well… you went from hardware accelerated blitting to mostly software
blitting, what did you expect?

A lot of people ask here “how do I make X faster” and the usual reply is
"reimplement using OpenGL". Why are you doing the opposite path? OpenGL
compatibility problems?

If your 2D code used OpenGL to render quads, your rendering logic is
probably redrawing everything each frame. You usually can’t do that in
2D software. But using a dirty rect approach gives acceptable results -
see http://www.mysterystudio.com/wildwestwendy.php for a lot of sprites
with alpha moving at the same time.

    --Gabriel

JF_Perusse · May 23, 2005, 6:46pm

Gabriel <mystml adinet.com.uy> writes:

    I hope any of you will have an idea why it is slower.
Well… you went from hardware accelerated blitting to mostly software
blitting, what did you expect?

A lot of people ask here “how do I make X faster” and the usual reply is
"reimplement using OpenGL". Why are you doing the opposite path? OpenGL
compatibility problems?

If your 2D code used OpenGL to render quads, your rendering logic is
probably redrawing everything each frame. You usually can’t do that in
2D software. But using a dirty rect approach gives acceptable results -
see http://www.mysterystudio.com/wildwestwendy.php for a lot of sprites
with alpha moving at the same time.
    --Gabriel

Well I tried switching to SDL in order to get DirectX acceleration under Windows
instead of OpenGL. My game works well when the graphics card offers a good
OpenGL acceleration, but I tried it on many very good computer and graphics card
where there was no good OpenGL acceleration, only good DirectX, and my game ran
very slowly So I thought SDL may be a good solution since a lot of 2D games
uses it… Isn’t there a way to get SDL hardware accelerated blitting with
DirectX? What would be the best solution?

Roman_Senn · May 23, 2005, 6:55pm

I’d be also interested in such a “dirty rectangle approach” but I
couldn’t find any article or sourcecode on the link you posted.
I have lots of sprites with alpha but only few of them moving at a time,
so drawing and updating only the areas in which something is moving
should be lots faster?!
If someone could point me to some information about blitting/updating approaches
in 2D mode or some sourcecode example of a “dirty rectangle approach” I’d be very glad.On Mon, 23 May 2005 15:04:15 -0300 Gabriel wrote:

If your 2D code used OpenGL to render quads, your rendering logic is
probably redrawing everything each frame. You usually can’t do that in
2D software. But using a dirty rect approach gives acceptable results -
see http://www.mysterystudio.com/wildwestwendy.php for a lot of sprites
with alpha moving at the same time.
    --Gabriel

atrix2 · May 23, 2005, 7:38pm

“but I tried it on many very good computer and graphics card where there was
no good OpenGL acceleration, only good DirectX”

wow that is a very sad state of affairs

I know with windows xp are shipped very lousy opengl drivers to make directx
seem better but you can update your drivers to overcome that. I don’t know
if this is what you are seeing on the other computers or not.

do you know what kind of video cards you tested this on?> ----- Original Message -----

From: jfperusse@gmail.com (JF Perusse)
To:
Sent: Monday, May 23, 2005 11:46 AM
Subject: [SDL] Re: OpenGL to SDL = Slower?
Gabriel <mystml adinet.com.uy> writes:
    I hope any of you will have an idea why it is slower.
Well… you went from hardware accelerated blitting to mostly software
blitting, what did you expect?

A lot of people ask here “how do I make X faster” and the usual reply is
"reimplement using OpenGL". Why are you doing the opposite path? OpenGL
compatibility problems?

If your 2D code used OpenGL to render quads, your rendering logic is
probably redrawing everything each frame. You usually can’t do that in
2D software. But using a dirty rect approach gives acceptable results -
see http://www.mysterystudio.com/wildwestwendy.php for a lot of sprites
with alpha moving at the same time.
    --Gabriel
Well I tried switching to SDL in order to get DirectX acceleration under
Windows
instead of OpenGL. My game works well when the graphics card offers a good
OpenGL acceleration, but I tried it on many very good computer and
graphics card
where there was no good OpenGL acceleration, only good DirectX, and my
game ran
very slowly So I thought SDL may be a good solution since a lot of 2D
games
uses it… Isn’t there a way to get SDL hardware accelerated blitting with
DirectX? What would be the best solution?

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

JF_Perusse · May 23, 2005, 8:14pm

Alan Wolfe <atrix2 cox.net> writes:

“but I tried it on many very good computer and graphics card where there was
no good OpenGL acceleration, only good DirectX”

wow that is a very sad state of affairs

I know with windows xp are shipped very lousy opengl drivers to make directx
seem better but you can update your drivers to overcome that. I don’t know
if this is what you are seeing on the other computers or not.

do you know what kind of video cards you tested this on?

One I can remember of is probably not a good exemple. My laptop is a Compaq
Presario with S3 ProSavage KN133 (Twister) video chipset. The OpenGL is very bad
on this computer and I normally have better performances with DirectX. I tried
my game on a very good computer at work and it ran very slowly, but like you
said, it may be related to the display drivers :S.

Staying with OpenGL may be the best solution… My biggest problem right now is
displaying fonts. I’m using glText, with textured base TrueType fonts in order
to get the antialiasing (or else the quality is horrible). (I also tried FTGL
but it was slower than glText) We have an in-game chat which costs us a lot of
FPS. (takes in average 10 to 100 more time to display than the game graphics!)
What I liked with SDL is that I could have many surfaces where I could keep pre
rendered stuff. This may have been a solution to keep text in such surfaces.

The solution of dirty rectangles may be something to consider. It gives me some
ideas about how I could higher our FPS. Right now, everything is drawn for each
frame. Since the chat messages are displayed “over” the game, I would have to
redraw the chat really often even with dirty rectangles. So, one solution would
be to change the UI in order to have the chat messages over a static background,
and draw only when new messages are added…

If ever you’re interested in seeing the actual game in action, it’s an Open
Source game called Hot Potato Online (see www.hotpotatoonline.com).

Thanks for your help!

JF Perusse -> ----- Original Message -----

From: “JF Perusse” <jfperusse gmail.com>
To: <sdl libsdl.org>
Sent: Monday, May 23, 2005 11:46 AM
Subject: [SDL] Re: OpenGL to SDL = Slower?
Gabriel <mystml adinet.com.uy> writes:
    I hope any of you will have an idea why it is slower.
Well… you went from hardware accelerated blitting to mostly software
blitting, what did you expect?

A lot of people ask here “how do I make X faster” and the usual reply is
"reimplement using OpenGL". Why are you doing the opposite path? OpenGL
compatibility problems?

If your 2D code used OpenGL to render quads, your rendering logic is
probably redrawing everything each frame. You usually can’t do that in
2D software. But using a dirty rect approach gives acceptable results -
see http://www.mysterystudio.com/wildwestwendy.php for a lot of sprites
with alpha moving at the same time.
    --Gabriel
Well I tried switching to SDL in order to get DirectX acceleration under
Windows
instead of OpenGL. My game works well when the graphics card offers a good
OpenGL acceleration, but I tried it on many very good computer and
graphics card
where there was no good OpenGL acceleration, only good DirectX, and my
game ran
very slowly So I thought SDL may be a good solution since a lot of 2D
games
uses it… Isn’t there a way to get SDL hardware accelerated blitting with
DirectX? What would be the best solution?

SDL mailing list
SDL libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Bob_Ippolito · May 23, 2005, 9:52pm

Alan Wolfe <atrix2 cox.net> writes:

“but I tried it on many very good computer and graphics card where
there was
no good OpenGL acceleration, only good DirectX”

wow that is a very sad state of affairs

I know with windows xp are shipped very lousy opengl drivers to
make directx
seem better but you can update your drivers to overcome that. I
don’t know
if this is what you are seeing on the other computers or not.

do you know what kind of video cards you tested this on?

One I can remember of is probably not a good exemple. My laptop is
a Compaq
Presario with S3 ProSavage KN133 (Twister) video chipset. The
OpenGL is very bad
on this computer and I normally have better performances with
DirectX. I tried
my game on a very good computer at work and it ran very slowly, but
like you
said, it may be related to the display drivers :S.

Staying with OpenGL may be the best solution… My biggest problem
right now is
displaying fonts. I’m using glText, with textured base TrueType
fonts in order
to get the antialiasing (or else the quality is horrible). (I also
tried FTGL
but it was slower than glText) We have an in-game chat which costs
us a lot of
FPS. (takes in average 10 to 100 more time to display than the game
graphics!)
What I liked with SDL is that I could have many surfaces where I
could keep pre
rendered stuff. This may have been a solution to keep text in such
surfaces.

The solution of dirty rectangles may be something to consider. It
gives me some
ideas about how I could higher our FPS. Right now, everything is
drawn for each
frame. Since the chat messages are displayed “over” the game, I
would have to
redraw the chat really often even with dirty rectangles. So, one
solution would
be to change the UI in order to have the chat messages over a
static background,
and draw only when new messages are added…

If ever you’re interested in seeing the actual game in action, it’s
an Open
Source game called Hot Potato Online (see www.hotpotatoonline.com).

Dirty rectangles doesn’t make sense for OpenGL, but display lists
might… especially for text that doesn’t change often.

-bobOn May 23, 2005, at 1:14 PM, JF Perusse wrote:

Stephane_Marchesin · May 23, 2005, 10:51pm

JF Perusse a ?crit :

Well I tried switching to SDL in order to get DirectX acceleration under Windows
instead of OpenGL. My game works well when the graphics card offers a good
OpenGL acceleration, but I tried it on many very good computer and graphics card
where there was no good OpenGL acceleration, only good DirectX, and my game ran
very slowly So I thought SDL may be a good solution since a lot of 2D games
uses it… Isn’t there a way to get SDL hardware accelerated blitting with
DirectX?

Well, most blits are accelerated, except alpha blits which you seem to
use a lot.
So that’s probably the reason for the slowdown you see.

What would be the best solution?

The best solution is pobably to implement hardware accelerated alpha
blits for the SDL directX backend.

Stephane

Gabriel_Gambetta · May 24, 2005, 3:01am

I have lots of sprites with alpha but only few of them moving at
a time, so drawing and updating only the areas in which
something is moving should be lots faster?!
Yes, of course.

The basic idea is to keep track of the areas of the screen that you
paint. For example, let’s say you have a background image. You blit the
character over it and update the screen. Next frame you move the
character, so you repaint the background over the old position of the
character, and blit the character in its new position. Note that these
two operations just touch the areas of the screen that actually change.
You keep track of these rectangles, where the contents of the back
buffer and the front buffer don’t match - and are called “dirty”, as in
"needing update".

After you processed your frame, you have the new frame you want to
display in the back buffer, the old frame still in the front buffer and
therefore on screen, and a list of rectangles specifying the parts of
the back and front buffers that don’t match. You then copy only these
areas from the back buffer to the front buffer, and discard the
rectangle list.

Of course this is only the general idea, there’s a lot of detail to
discuss. I described double buffering here, but it will work with page
flipping too, with some modifications.

One of the important points is what you do with what I just described as
a “rectangle list”. It’s not that easy in practice. Yes, you could
update every rect in the list, but you could get a lot of overlap and
therefore extra work.

You can do some rectangle merging and splitting code. You can also use
tile arrays (divide your screen in fixed size squares, say 64x64, and
whenever a dirty rect overlaps a tile, mark the whole tile as dirty) -
draws more than needed, but it’s very easy to implement and performs
well. You can go further and use micro tile arrays, which involve
keeping track of dirty sub-rectangles inside each tile and merge them
before updating, which tends to be easier than a general rectangle
merge, and does a lot less overdraw. This is what I’m currently using.

Hope that helps! As always, Google is your friend.
–Gabriel