Sprite drawing

SDL Development
1

I clear my sprites from the screen by keeping a copy of the background the size of the sprite which I blit over the sprite. This works just great until you have two sprites moving above each other. Then the copy of the background will become outdated when the sprites move and as result leave trails of trash on the screen.

How do you fix this?–
// Jacob Persson
// @Jacob_Persson

2

Right.
Okay, do your sprite drawing as a two phase action.
First, whenever you need to draw a sprite clear the area where they
currently are, and add the sprite id, x,y coordinates to a list.

Then, when all sprites that are to be drawn had their area clear and their
request queued, loop through the list and actually draw the sprite.

Simple, although I’m sure there are far more sophisticated and 'nice’
solutions.> ----- Original Message -----

From: straver@apollo.nu (Jacob Persson)
To:
Sent: Thursday, July 24, 2003 11:53 AM
Subject: [SDL] sprite drawing

I clear my sprites from the screen by keeping a copy of the background the
size of the sprite which I blit over the sprite. This works just great until
you have two sprites moving above each other. Then the copy of the
background will become outdated when the sprites move and as result leave
trails of trash on the screen.

How do you fix this?

–
// Jacob Persson
// straver at apollo.nu

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

3

Instead of keeping a copy of the background under the sprite, keep a
copy of the whole background. Keep track of the location and area the is
overwritten by each sprite. When a sprite moves, do the same thing you
do now, but use the clean background copy as the source.

Down side, you have to keep around a copy of the background.
Up side, it is likely to be faster than copying the background.

Or, if you can detect when sprites overlap, you can merge the rectangles
for two or more sprites into a rectangle that contains all the
overlapping sprites.

	Bob PendletonOn Wed, 2003-07-23 at 20:53, Jacob Persson wrote:

I clear my sprites from the screen by keeping a copy of the background the size of the sprite which I blit over the sprite. This works just great until you have two sprites moving above each other. Then the copy of the background will become outdated when the sprites move and as result leave trails of trash on the screen.

How do you fix this?

–
±----------------------------------+

4

Hi,

about your problem, the best would be in the game_loop:

  • redraw the saved background for all the sprites
  • do keyboard handling and other stuff that might move your sprites
  • save the background for every sprite
  • draw all the sprites

The solution in my game is diffrent because i have a kind of tileset game,
but it should work in any other type of game too:

  • i created me a list with everything what needs to be painted,
    in this list i filter out what would be painted double. Like two
    sprites at the same place. So i need to paint the background only once.
  • i don’t save the orginal background from the sprites. I redraw only this
    part of the background/field. (that gives me some more time because i don’t
    need to save the old background data)
  • in the end of the game loop i draw everything in the list ordered by a priority
    what have to painted first (like old backgrounds) and what have to be painted
    at last like sprites.
  • while i paint it i fill everything in a little list of updated rects on
    the screen, which is even filtered off double paintings. And i give this list
    to SDL_UpdateRects (…); So i don’t need to use the slow SDL_Flip function.

i hope it will help you a little bit.

bye bye
Steffen–

Steffen Pohle (@Steffen_Pohle)| _ x
http://stpohle.bei.t-online.de | /#/ BomberClone - The Clone of
JabberID: stpohle at amessage.de ||###| DynaBlaster and Bomberman
ICQ: 370965 Yahoo: stpohle | #/ http://www.bomberclone.de
MSN: stpohle at hotmail.com |

5

— Bob Pendleton wrote:> On Wed, 2003-07-23 at 20:53, Jacob Persson wrote:

I clear my sprites from the screen by keeping a copy of the
background the size of the sprite which I blit over the sprite.
This works just great until you have two sprites moving above each
other. Then the copy of the background will become outdated when
the sprites move and as result leave trails of trash on the screen.

How do you fix this?

Instead of keeping a copy of the background under the sprite, keep a
copy of the whole background. Keep track of the location and area the
is overwritten by each sprite. When a sprite moves, do the same thing
you do now, but use the clean background copy as the source.

Down side, you have to keep around a copy of the background.
Up side, it is likely to be faster than copying the background.

Or, if you can detect when sprites overlap, you can merge the
rectangles for two or more sprites into a rectangle that contains
all the overlapping sprites.

In my current project, my game background (composed somewhat
complexly) extends beyond the bounds of the screen. The entire
SDL_Surface representing the background is stored and portions of it
are blitted to mainDisplay to display appropriate scrolling every time
through the game loop. Then, every Actor in the system is then blitted
over the top of that fresh background.

There are optiomizations to be performed here where only parts of the
background are invalidated and redrawn between frames, but with the
amount of random sprites and particles I have running around, I’m not
sure doing many small blits, one for each invalid portion, is cheaper
than doing the one big background blit and then redrawning the Actors.

                                                        NBarnes

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

6

Jacob Persson wrote:

I clear my sprites from the screen by keeping a copy of the background the size of the sprite which I blit over the sprite. This works just great until you have two sprites moving above each other. Then the copy of the background will become outdated when the sprites move and as result leave trails of trash on the screen.

How do you fix this?

Try restoring the background in the opposite order in which you draw the
sprites.

Drirr.

7

Instead of copying the actual graphics beneath a sprite, just let your
program remember the rectangle which your sprite is over. Now, to
clear the screen back to the “only background shown” state, just copy
the rectangle parts from the background image to the screen.

Of course, this assumes you want to keep a separate copy the
background picture in memory, separate from the screen surface, that
is.

Hope that is understandable,

/Olof

Jacob Persson: “[SDL] sprite drawing” (2003-07-24 03:53)

#I clear my sprites from the screen by keeping a copy of the
#background the size of the sprite which I blit over the sprite. This
#works just great until you have two sprites moving above each other.
#Then the copy of the background will become outdated when the sprites
#move and as result leave trails of trash on the screen.#
#How do you fix this?

#–
#// Jacob Persson
#// straver at apollo.nu

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

8

Hello,

I was wondering if SDL’s pixel data for each surface is machine byte order
dependent?

In other words, I would like to transfer the binary pixel data from one
computer to another. So, do I need to run each 16 bit pixel that I transfer
through any network byte order function such as SDLNet_Write16/SDLNet_Read16
or htons/ntohs?

Thank you,
David and Blake

9

Hello,

I was wondering if SDL’s pixel data for each surface is machine byte order
dependent?

In other words, I would like to transfer the binary pixel data from one
computer to another. So, do I need to run each 16 bit pixel that I transfer
through any network byte order function such as SDLNet_Write16/SDLNet_Read16
or htons/ntohs?

Thank you,
David and Blake

10

I suggest transferring data in network byte order, and in RGB format
rather than 16-bit format. That allows maximum compatibility.

As I recall from some post way back, I think the bits are stored in
graphics card order. This is usually the machine byte order, but
sometimes it’s not.

So if you send data from big-endian system with little-endian graphics
card, to a big-endian system with big-endian graphics card, then
transferring data only in network byte order doesn’t do you much good
because the data wasn’t byte-ordered correctly from the source graphics
card to the source CPU. So transferring data in RGB format would be
required in such a case.

I’m just deducting from what I’ve read before. I could be horribly wrong.

-MarkOn Thu, 24 Jul 2003, Blake D wrote:

Hello,

I was wondering if SDL’s pixel data for each surface is machine byte order
dependent?

In other words, I would like to transfer the binary pixel data from one
computer to another. So, do I need to run each 16 bit pixel that I transfer
through any network byte order function such as SDLNet_Write16/SDLNet_Read16
or htons/ntohs?

Thank you,
David and Blake

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

–
Mark K. Kim
http://www.cbreak.org/
PGP key available upon request.

11

I suggest transferring data in network byte order, and in RGB format
rather than 16-bit format. That allows maximum compatibility.

Well, yes, byte order is significant, but you can build a surface with
a specific format…but this could cause performance hits in rendering.

Also ask yourself if transferring bitmaps over the network is really a
good use of bandwidth. Perhaps send the data needed to rerender it
remotely instead?

–ryan.