Sprite Game

Herbert_G_Fischer · June 23, 2003, 9:29pm

Hi,

I’m learning game devel with SDL and I have a basic doubt.

What’s the best method to do sprite basic animation ?

repaint entire background each loop and paint sprites on it ?

or

maintain background safe, doing backups from part of background for
each sprite painted ?

The second method is a lot confunsing to implement.

Anyone knows some tutorial about this, preferably using SDL, that
shows me different methods, and what I can expect from each one and
how can I implement them ?

Thanks,

Herbert

Clemens_Kirchgattere · June 23, 2003, 10:12pm

“H. G. Fischer” wrote:

What’s the best method to do sprite basic animation ?

repaint entire background each loop and paint sprites on it ?

or

maintain background safe, doing backups from part of background for
each sprite painted ?

the latter.

The second method is a lot confunsing to implement.

it’s not that complicated.

look at the sprite as an object. so a little bit of OOP comes in
handy. either write a class in c++ or a struct in c, throw in the int x,
y postition, forground and background SDL_Surfaces and implement one or
more functions to do the blit…

typdef struct Sprite {
int x, y;
SDL_Surface *fg, *bg;
} Sprite;

Sprite *new_Sprite(int w, inh h [, SDL_Image *img | SDL_Surface *spr]);
void blit_Sprite(Sprite *spr);
void del_Sprite(Sprite *spr);

hopefully that gets you started.

best regards …
clemens

Bill_Kendrick · June 23, 2003, 10:56pm

Hi,

I’m learning game devel with SDL and I have a basic doubt.

What’s the best method to do sprite basic animation ?

repaint entire background each loop and paint sprites on it ?

or

maintain background safe, doing backups from part of background for
each sprite painted ?

The second method is a lot confunsing to implement.

It really depends. In most of my games, I’m lazy, and redraw everything.
This can cause a speed hit, but as you see, it’s simple. :^)

I try to only do this in games where lots of things are moving around.
(It wouldn’t be worth it to update dozens of little places.)

Anyone knows some tutorial about this, preferably using SDL, that
shows me different methods, and what I can expect from each one and
how can I implement them ?

I don’t know of any off-hand, but I’m sure they must exist.

There are also libraries that go “on top” of SDL that provide a
more abstracted “sprite” concept, and may be worth looking into.
(I’ve honestly never used them, myself.)

Good luck!

-bill!On Tue, Jun 24, 2003 at 01:28:03AM -0300, H. G. Fischer wrote:

–
bill at newbreedsoftware.com Got kids? Get Tux Paint!
Bill Kendrick Tux Paint - Free art software for kids of all ages

Nikolaos_Theologou · June 23, 2003, 11:47pm

Here, take a look at this.
http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/gfxsdl/tut3

Hope you find it useful.

-Nikolaos Theologou–
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Bitte l?cheln! Fotogalerie online mit GMX ohne eigene Homepage!

David_Olofson · June 24, 2003, 1:34am

Hi,

I’m learning game devel with SDL and I have a basic doubt.

What’s the best method to do sprite basic animation ?

repaint entire background each loop and paint sprites on it ?

or

maintain background safe, doing backups from part of background
for each sprite painted ?

If you have lots of sprites, or (obviously) if you’re scrolling the
screen as well, the former is the way to go. It’s also much more
reliable (or rather, a lot easier to get right) if you want to
support various kinds of displays. Most importantly, h/w page
flipping displays complicate the second approach a bit.

Either way, if you’re going for the second approach, keep in mind that
reading from the display surface is normally (*) very expensive if
it’s a hardware surface. This applies for glSDL as well, BTW. Most
OpenGL implementations seem to fall back to software blitting when
reading or writing pixels from/to the display buffer.

You’re much better off removing sprites by other means than keeping
backups. (Besides, you have to make sure the screen is in the right
state before you grab those backsave rects.)

One way is to simply redraw the area of the background covered by each
sprite you want to remove. (That is, render tiles from the map, or
whatever.) This is usually simple and effective, and doesn’t require
any extra memory for backsave. If you have very expensive background
rendering (such as multilayered tiles with blending and stuff, “real
time” raytraced backgrounds or whatever), you’re probably better off
using some other method. Such as…

…keeping an extra back buffer for background rendering only. Do
whatever you need to render the background into that buffer, and then
blit from there to initialize the screen. (You’ll have to do the
latter twice for a h/w page flipping double buffered display.) Then
keep the back buffer for sprite removal through plain blitting.

(*) The only exception is integrated chipsets that use a system
RAM area as VRAM. Those don’t have PCI or AGP between the
CPU and VRAM, so the 386 + VGA class bottleneck is avoided.
Atari ST and TT, Commodore Amiga (using OCS, ECS or AGA) and
most older consoles work in similar ways. I believe the XBox
has the same issue as any PC, but I don’t know about the PS2.

The second method is a lot confunsing to implement.

That goes for pretty much everything but the plain brute force
approach.

Anyone knows some tutorial about this, preferably using SDL, that
shows me different methods, and what I can expect from each one and
how can I implement them ?

Well, I’m planning to hack a demo + documentation, covering the most
common methods, how to deal with h/w page flipping etc. Can’t do it
right now, though. (Work, Kobo Deluxe, Audiality, Real Life etc.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Tuesday 24 June 2003 06.28, H. G. Fischer wrote:

Herbert_G_Fischer · June 24, 2003, 6:07am

Clemens Kirchgatterer wrote:

“H. G. Fischer” <@Herbert_G_Fischer> wrote:

What’s the best method to do sprite basic animation ?

repaint entire background each loop and paint sprites on it ?

or

maintain background safe, doing backups from part of background for
each sprite painted ?

the latter.

The second method is a lot confunsing to implement.

it’s not that complicated.

look at the sprite as an object. so a little bit of OOP comes in
handy. either write a class in c++ or a struct in c, throw in the int x,
y postition, forground and background SDL_Surfaces and implement one or
more functions to do the blit…

typdef struct Sprite {
int x, y;
SDL_Surface *fg, *bg;
} Sprite;

Sprite *new_Sprite(int w, inh h [, SDL_Image *img | SDL_Surface *spr]);
void blit_Sprite(Sprite *spr);
void del_Sprite(Sprite *spr);

hopefully that gets you started.

best regards …
clemens

Thanks!

Herbert_G_Fischer · June 24, 2003, 6:12am

Bill Kendrick wrote:

Hi,

I’m learning game devel with SDL and I have a basic doubt.

What’s the best method to do sprite basic animation ?

repaint entire background each loop and paint sprites on it ?

or

maintain background safe, doing backups from part of background for
each sprite painted ?

The second method is a lot confunsing to implement.

It really depends. In most of my games, I’m lazy, and redraw everything.
This can cause a speed hit, but as you see, it’s simple. :^)

I try to only do this in games where lots of things are moving around.
(It wouldn’t be worth it to update dozens of little places.)

Thanks!

Anyone knows some tutorial about this, preferably using SDL, that
shows me different methods, and what I can expect from each one and
how can I implement them ?

I don’t know of any off-hand, but I’m sure they must exist.

There are also libraries that go “on top” of SDL that provide a
more abstracted “sprite” concept, and may be worth looking into.
(I’ve honestly never used them, myself.)

I want to write myself to learn the best of SDL. I think that using
something done will limit my knowledge and even difficult my “work”
when I get some problems in the future.> On Tue, Jun 24, 2003 at 01:28:03AM -0300, H. G. Fischer wrote:

Good luck!

-bill!

Herbert_G_Fischer · June 24, 2003, 6:13am

Thanks!

Nikolaos Theologou wrote:> Here, take a look at this.

http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/gfxsdl/tut3

Hope you find it useful.

-Nikolaos Theologou

Gabriel_Gambetta · June 24, 2003, 6:16am

One way is to simply redraw the area of the background covered by each

sprite you want to remove. (That is, render tiles from the map, or
whatever.) This is usually simple and effective, and doesn’t require
any extra memory for backsave.

That’s similar to what I have in my current library; for dirty
rectangles, I draw the background and then the sprites in Z order.

Precisely, I was thinking about this lately and I was about to ask.
Right now, I just join the updated rects to get one update rectangle
which I then blit at the end of the frame. This means, for example, that
if the upper-left and the lower-right pixel change, I end up updating
the whole screen. This was a hack, obviously, but it worked well for
what I was doing.

I’m looking for a more general solution. The Right Thing should be doing
the exact rectangle joins and division to get a list with exactly what
must be blitted. However, I guess the overhead of maintaining the list
isn’t worth the effort nowadays - I believe it’s better to have some
overdraw and a simple dirty rect approach.

I’m thinking about dividing the screen in homogeneous patches, say,
10x10 patches, and mark them as dirty if a sprite which overlaps them
must be redrawn. Actually, I implemented something like this for the
case when my library renders the sprites over an OpenGL context - I
maintain a list of patches, each with an associated texture which gets
uploaded only when the corresponding section of the framebuffer changes,
and gets blitted every frame.

Is this the “canonical” way of doing things? Do everyone else do The
Right Thing ™ in regard to dirty rects, or this dirty approach is OK?

Thanks,
–Gabriel

Lic. Gabriel Gambetta
ARTech - GeneXus Development Team
ggambett at artech.com.uy

Herbert_G_Fischer · June 24, 2003, 6:46am

Very Thanks!!

Your answer was very helpfull!

David Olofson wrote:> On Tuesday 24 June 2003 06.28, H. G. Fischer wrote:

Hi,

I’m learning game devel with SDL and I have a basic doubt.

What’s the best method to do sprite basic animation ?

repaint entire background each loop and paint sprites on it ?

or

maintain background safe, doing backups from part of background
for each sprite painted ?

If you have lots of sprites, or (obviously) if you’re scrolling the
screen as well, the former is the way to go. It’s also much more
reliable (or rather, a lot easier to get right) if you want to
support various kinds of displays. Most importantly, h/w page
flipping displays complicate the second approach a bit.

Either way, if you’re going for the second approach, keep in mind that
reading from the display surface is normally (*) very expensive if
it’s a hardware surface. This applies for glSDL as well, BTW. Most
OpenGL implementations seem to fall back to software blitting when
reading or writing pixels from/to the display buffer.

You’re much better off removing sprites by other means than keeping
backups. (Besides, you have to make sure the screen is in the right
state before you grab those backsave rects.)

One way is to simply redraw the area of the background covered by each
sprite you want to remove. (That is, render tiles from the map, or
whatever.) This is usually simple and effective, and doesn’t require
any extra memory for backsave. If you have very expensive background
rendering (such as multilayered tiles with blending and stuff, “real
time” raytraced backgrounds or whatever), you’re probably better off
using some other method. Such as…

…keeping an extra back buffer for background rendering only. Do
whatever you need to render the background into that buffer, and then
blit from there to initialize the screen. (You’ll have to do the
latter twice for a h/w page flipping double buffered display.) Then
keep the back buffer for sprite removal through plain blitting.

(*) The only exception is integrated chipsets that use a system
RAM area as VRAM. Those don’t have PCI or AGP between the
CPU and VRAM, so the 386 + VGA class bottleneck is avoided.
Atari ST and TT, Commodore Amiga (using OCS, ECS or AGA) and
most older consoles work in similar ways. I believe the XBox
has the same issue as any PC, but I don’t know about the PS2.

The second method is a lot confunsing to implement.

That goes for pretty much everything but the plain brute force
approach.

Anyone knows some tutorial about this, preferably using SDL, that
shows me different methods, and what I can expect from each one and
how can I implement them ?

Well, I’m planning to hack a demo + documentation, covering the most
common methods, how to deal with h/w page flipping etc. Can’t do it
right now, though. (Work, Kobo Deluxe, Audiality, Real Life etc.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

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