I was hoping to find an answer without disturbing the flow of
information with a newbie question, but here we are.
I recently started using SDL for a project and have found that
UpdateRect’ing the whole window (or Flip’ing for that matter) at 800x600
is, what seems to me, unusually slow. I’m really looking for
comparative commentary here, to figure out if I’m doing something really
wrong.
I ran various quick tests (read: looping around updating with some
pictures lying about) as well as the latest version of defenguin, at
they all checked in at “there, but not playable”. My machine is an AMD
K6-350 with 64MB of RAM, a Matrox Mystique 220, and RedHat 5.2. Not a
speed demon, granted, but not that much of a dog (sound of hope
fading).
Wisdom, comments, experience, flames, or even “You’re stupid. Mine is
fast.” appreciated.
I was hoping to find an answer without disturbing the flow of
information with a newbie question, but here we are.
I recently started using SDL for a project and have found that
UpdateRect’ing the whole window (or Flip’ing for that matter) at 800x600
is, what seems to me, unusually slow. I’m really looking for
comparative commentary here, to figure out if I’m doing something really
wrong.
I ran various quick tests (read: looping around updating with some
pictures lying about) as well as the latest version of defenguin, at
they all checked in at “there, but not playable”. My machine is an AMD
K6-350 with 64MB of RAM, a Matrox Mystique 220, and RedHat 5.2. Not a
speed demon, granted, but not that much of a dog (sound of hope
fading).
Well, there’s a few things to keep in mind. First of all, Sam hasn’t really
optimized much of the code AFAICT, so it’s still kind of slow in places,
especially where alpha blitting is concerned. My project this winter is to
work on SDL, and one of the areas is optimization. The other thing that
might do it IMHO is that you are running under X in a really big window,
which isn’t really designed for that sort of thing. If you want to do that,
stick SDL in fullscreen mode or go with another renderer (the experimental
SVGAlib one, GGI perhaps).
No worries about disturbing the flow of information… we’re still working
away here!
emmett
Nicholas
----- Original Message -----
From: rtomai@yahoo.com (Emmett Tomai)
To: sdl at lokigames.com
Date: Tuesday, December 14, 1999 6:41 PM
Subject: [SDL] Sigh. Newbie Performance Q
Well, there’s a few things to keep in mind. First of all, Sam hasn’t really
optimized much of the code AFAICT, so it’s still kind of slow in places,
especially where alpha blitting is concerned. My project this winter is to
work on SDL, and one of the areas is optimization. The other thing that
might do it IMHO is that you are running under X in a really big window,
which isn’t really designed for that sort of thing. If you want to do that,
stick SDL in fullscreen mode or go with another renderer (the experimental
SVGAlib one, GGI perhaps).
Actually, the SDL code is designed to stay out of your way, and common
code paths are VERY optimized. That said, alpha blending is one place
that is still very slow because nobody has written any special-case
blitters for it. (Yes, I am aware of Hermes - I just don’t include
most of its blitters to avoid code bloat)
The biggest thing to think about when checking update speed is to check
whether or not SDL is performing dynamic pixel conversion for you. The
best thing to do is to specify a depth of zero when setting the video
mode, and then check the actual bit-depth that is returned.
The fastest “truecolor” configuration is the display set to 16bpp with
you converting all your graphics to the display format.
In general, the fullscreen and SVGAlib and GGI targets are all slower
than windowed display using the native X11 driver on an accelerated
X server, for various reasons.
Benchmark your code in several different environments and settings
to see what works best for you.
Actually, the SDL code is designed to stay out of your way, and common
code paths are VERY optimized. That said, alpha blending is one place
that is still very slow because nobody has written any special-case
blitters for it. (Yes, I am aware of Hermes - I just don’t include
most of its blitters to avoid code bloat)
Actually, the SDL code is designed to stay out of your way, and common
code paths are VERY optimized. That said, alpha blending is one place
that is still very slow because nobody has written any special-case
blitters for it. (Yes, I am aware of Hermes - I just don’t include
most of its blitters to avoid code bloat)
[snip]
Geh… well, you’re the man behind it!
Hey, if you have a special need for a general blitter, let me know, and
I’ll include your submission!
Actually, the SDL code is designed to stay out of your way, and common
code paths are VERY optimized. That said, alpha blending is one place
that is still very slow because nobody has written any special-case
blitters for it. (Yes, I am aware of Hermes - I just don’t include
most of its blitters to avoid code bloat)
Hermes 1.2.6 doesn’t have support for alpha and colorkeying (blitting and
conversion). Only a hacked version that ClanLib uses has. Well, why don’t
you link against Hermes if you use it? Why not integrate the blitters/
converters SDL uses into Hermes?On Tue, 14 Dec 1999, Sam Lantinga wrote:
It seems to have i386 asm routines for alpha blits.
NeilOn Wed, 15 Dec 1999, Daniel Vogel wrote:
On Tue, 14 Dec 1999, Sam Lantinga wrote:
Actually, the SDL code is designed to stay out of your way, and common
code paths are VERY optimized. That said, alpha blending is one place
that is still very slow because nobody has written any special-case
blitters for it. (Yes, I am aware of Hermes - I just don’t include
most of its blitters to avoid code bloat)
Hermes 1.2.6 doesn’t have support for alpha and colorkeying (blitting and
conversion). Only a hacked version that ClanLib uses has. Well, why don’t
you link against Hermes if you use it? Why not integrate the blitters/
converters SDL uses into Hermes?
Hey, if you have a special need for a general blitter, let me know, and
I’ll include your submission!
Just a thought, it would be cool if you could add something to modify the
pixel value right before blitting it. Like say you wanted to draw only the
RED value in a sprite. You could take the pixel, AND it by 111110000000000b
assuming it’s 16-bit. Hmm… maybe I’ll start looking through some of that
blitter code…–
-= aaron p. matthews
-= rival entertainment
-= http://www.Nayzak.com/~jerryma/rival
