Hi Folks,
I’m a total n00b at graphics programming so go easy on me…
I’m using the SDL_image library to load PNG files. When I try to
scroll one image (and yes it is a screen-size graphic…) the
performance is terrible, like painfully slow. If however, I convert
the image to BMP - it’s so much faster, but of course you lose the
alpha capabilities.
(Of course, you can remove the alpha channel from the PNG image for
the same effect. PNG supports everything that BMP does, and much
more.)
So, why is this? I’ve got a 1.5Ghz PC (512mb) with 64mb shared VRAM.
I also tried it on another system with 1GB RAM, and the same deal.
One system is XP, the other 2K.
There are a few problems with alpha blending; some specific to current
versions of SDL, others related to drivers and rendering APIs;
1) Alpha blending is generally not supported by (old,
widely supported) 2D rendering APIs, so SDL has to
implement it in software.
2) Software alpha blending is a relatively expensive
operation. (A few multiplies, adds and other
operations per pixel.)
3) Alpha blending requires reading from the target
surface - and reading from VRAM is *extremely*
slow on most modern hardware.
Solutions:
1) Use a modern 2D rendering API with alpha blending
support (which at least allows drivers to make use
of hardware acceleration), or a 3D API, like
DirectGraphics/Direct3D or OpenGL.
The glSDL backend allows normal “SDL 2D” code
to use OpenGL for rendering, but is, AFAIK, not
yet available in official/stable SDL.
2) Not much to do about this, really... Custom SIMD
code (very CPU specific!) can help. The SDL
blitters have slightly faster special cases for
fully opaque, fully transparent and 50%
translucent pixels.
Also, the RLE acceleration can speed up
software blitting in general quite a bit, so make
sure to request that!
3) Do not render directly into VRAM if you're using
substantial amounts of alpha blending. Use a
software display surface instead, or (preferably)
do the rendering in your own shadow software
surface, and then blit that (or just the modified
areas of it, unless you're scrolling or something)
to the screen. Using your own shadow surface
allows you to get a double buffered display with
hardware page flipping and retrace sync (to
eliminate tearing) when available, whereas
relying SDL's software shadow will invariably
put you in some form of unsync'ed single buffer
mode.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Thursday 30 March 2006 18:36, Edward Byard wrote:
