Hi, I’m new to SDL. I’m trying to write a very simple animation using
SDL. I want to move a BMP (a small ball image) on a background image
from one point to another point(from left of the screen to the right of
the screen). Should I follow the following steps?
1.) SDL_BlitSurface (background) to screen
2.) SDL_BlitSurface (Ball) to screen
3.) SDL_Flip(screen)
4.) update the new coordinate for the Ball (maybe ball.x++, ball.y++)
5.) repeat step 1-4
This is the approach I’m using.
Yeah, this is basically what most full screen scrolling games do. (Kobo
Deluxe, my SDL port of XKobo, would be one example - although it actually
redraws only the display window; not the “dashboard”.)
But to me, I think repeating step 1 is
not neccessary and “could” take too much time.
In fact, it will take pretty much time - on some systems and targets,
enough that you’ll end up with an unplayable frame rate even in rather
moderate resolutions. If you really have to animate the full screen,
there’s nothing much to do, short of using OpenGL, or (in the case of
Linux, for example) fixing the drivers.
But if I’m not blitting
the background back to the screen. How do I erase the “old” ball from
the screen before I draw the new ball?
Just pass a source rectangle to SDL_BlitSurface(), and you’ll be able to
blit just a part of the background image.
Just keep in mind that it’s not the control system’s “last object
coordinates” you should use, but the “last object coordinates” of the
respective page. Standard double buffering animation problem. 
I usually set up one set of “rendering information” for each display
page, and then just flip these sets when I flip the screen pages. That
way, when it’s time to update an old back buffer, the rendering info for
what’s already in that buffer is still there. Add sufficiently smart
algorithm for updating a buffer + “rendering info set” to match the
current state of the engine.
I remember in Dos C, there is a
command called putimage() and getimage(). Is there any thing like that
in SDL?
Yeah, kind of. The major difference here is that in the case of the SDL
API, someone was actually thinking while designing it.
The deal is basically that Everything Is A Surface. SDL_BlitSurface()
blits back and forth between rectangular areas whithin surfaces -
accelerated whenever possible - and the screen is just another surface in
this respect.
However, there is a major problem with the screen: On many targets,
blitting from the screen is extremely slow. (Many times slower than
blitting to it, and even that is very slow!)
So, the “copy from screen to sprite backsave” strategy may be fine for
mouse cursors and the like, but please DON’T use it for animation of
more than a few percent of the screen area. Too many targets will give
you a frame rate reminding of software OpenGL if you do that. heh
Am I doing this the wrong way?
No, you’re on the right track. You just need to optimize a little.
Is storing a surface in software (SW_SURFACE) faster than storing a
surface in Hardware (HW_SURFACE)? or the other way around?
Depends on what you’re going to do. First of all; unless surfaces in a
blit have compatible pixel formats, blitting will be slow. Use
SDL_DisplayFormat().
Now that you have two compatible surfaces, depending on where they are
stored, there are four distinctly different cases:
1. soft -> soft
Fast, thanks to great blitter code in SDL. However,
do note that general purpose CPUs suck at image
processing, such as alpha blending. Not much SDL
can do about that. Keep in mind that SDL supports
RLE encoded blits, so colorkey blitting can be
done without performance impact. (Since
transparent areas are just skipped, it may actually
be *faster* than opaque blits, in relation to the
blit rectangle area.)
2. soft -> hard
On some targets, it's possible to get this h/w
accelerated, which will be at least as fast as 1.
However, if it's *not* h/w accelerated, it will
be much slower than 1. (Unless you have a very
slow CPU, or an integrated video card that uses
system RAM for VRAM. :-)
3. hard -> soft
Usually accelerated when 2 is, I guess, but if
this one is *not* accelerated, prepare for the
word "slow" to be redefined. Reading VRAM with
the CPU is something you just don't do on modern
machines.
4. hard -> hard
The most commonly available form of h/w
acceleration. Can be very, very fast, and often
supports colorkey blitting. Of course, if it's
*not* h/w accelerated, you end up with something
that's even slightly slower than hard->soft w/o
h/w acceleration above...
Note that alpha blending isn’t supported by h/w accelerated targets in
general, so you may end up software blitting even if opaque and
colorkeyed blits are h/w accelerated. Recent version of a few APIs do
support alpha blending, but AFAIK, SDL doesn’t support any of them yet.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 20 November 2001 02:25, SDL SDList wrote: