The easiest thing to do is create another surface (either use
SDL_CreateRGBSurface, or load your bitmap into another surface) and
before you blit your bitmap to the display, blit the portion of the
display under it to the second surface. Before you move the sprite,
but after you display it on the screen, redraw the part of the
background you saved on top of your bitmap. Lather, Rinse, and
Repeat.
Martin Donlon wrote:Date: Sun, 27 Feb 2000 18:52:25 +0000
On Sun, 27 Feb 2000 hayward at slothmud.org wrote:
Only problem is, if a sprite walks so that he overlaps another sprite,
you end up saving the sprite under him as the background image.
Depending on the order and how you do it, you may end up erasing the
other sprite… or leaving a trace of a sprite where it shouldn’t be.
To avoid this you can simply use a three pass method to drawing each
frame.
Pass 1: Draw old "save unders"
Pass 2: Save the new ones
Pass 3: Draw your sprites
Personally, like yourself, I prefer a complete redraw, certainly when the
backgrounds are not static.
Long live the confused,
Akawaka.
Bother, said Pooh, as he carved Eeyore’s name into the black candle.
This should never be a problem if you erase them in reverse of the
order that you drew them in the first place.
ex.
Save Background Draw Sprite 1
Save BG, Draw Sprite 2
Save BG, Draw Sprite 3
Update Display
Erase Sprite 3
Erase Sprite 2
Erase Sprite 1
Repeat
It is still an issue because your “save under” code must be much more
complicated.
Think about this:
sprite1 appears
sprite2 appears in front of sprite one(Saving backgrnd w/sprite1 in it)
now sprite1 leaves.
You have to update sprite2’s background because sprite1 has left and thus
changed the pixels behind sprite2.
Thats the point I was making. It is an issue because you have to add more
complication and you can’t just set a background for a sprite only when
that sprite moves. When any sprite moves, you have to update the
save-under for all sprites above it.
It’s just more complicated than a simple… “save under” on a per-sprite
basis.–
Brian
Begin Loop
Move Sprites
Save Background under Sprite 1
Sprite 1 gets drawn
Save Background under Sprite 2, this saves part of sprite 1
Draw Sprite 2, that part gets obliterated
Refresh Display, Sprites Are Visible
Redraw Saved BG for Sprite 2, redraws obliterated part of Sprite 1
Redraw Saved BG for Sprite 1, should fully restore BG with Sprite 2
gone
Loop
The only way this could fail is if a sprite is removed before it is
erased, that should be handled in the move sprite part of the code, so
it is taken care of before anything is drawn, I have used this method
on several occasions and never had a problem with the display being
restored in correctly, and it has never made my sprite functions more
complicated than having a list of sprites, blitting through it from
start to finish, and erasing by going from finish to start.
It could however fail if your sprites were not all drawn and erased
in one fell swoop, but that’s how all my code is written.
hayward at slothmud.org wrote:> >This should never be a problem if you erase them in reverse of the
order that you drew them in the first place.
ex.
Save Background Draw Sprite 1
Save BG, Draw Sprite 2
Save BG, Draw Sprite 3
Update Display
Erase Sprite 3
Erase Sprite 2
Erase Sprite 1
Repeat
It is still an issue because your “save under” code must be much more
complicated.
Think about this:
sprite1 appears
sprite2 appears in front of sprite one(Saving backgrnd w/sprite1 in it)
now sprite1 leaves.
You have to update sprite2’s background because sprite1 has left and thus
changed the pixels behind sprite2.
Thats the point I was making. It is an issue because you have to add more
complication and you can’t just set a background for a sprite only when
that sprite moves. When any sprite moves, you have to update the
save-under for all sprites above it.
It’s just more complicated than a simple… “save under” on a per-sprite
basis.
It could however fail if your sprites were not all drawn and erased
in one fell swoop, but that’s how all my code is written.
Right… I was just trying to get the point across that moving a sprite is
not as easy as “drawing it’s own saved background”, then moving the
sprite, than restoring it’s background. This is fairly obvious though.
You don’t necessarily have to redraw all sprites either… just the ones
that overlap the moving sprites. It sounds like you redraw all sprites if
one moves…–
Brian
Yeah, it is kind of narrow thinking on my part. All of the code I
write has a combination of tile drawn backgrounds and constantly
moving and/or animated sprites so I always redraw all of my sprites
every pass through the loop. This is also the easiest method to do
unless you need the performance boost of selectively drawing only the
recquired sprites per frame.
hayward at slothmud.org wrote:> >It could however fail if your sprites were not all drawn and erased
in one fell swoop, but that’s how all my code is written.
Right… I was just trying to get the point across that moving a sprite is
not as easy as “drawing it’s own saved background”, then moving the
sprite, than restoring it’s background. This is fairly obvious though.
You don’t necessarily have to redraw all sprites either… just the ones
that overlap the moving sprites. It sounds like you redraw all sprites if
one moves…
why not just keep the whole background somewere else and blit from it only
the parts that were changed? (sorry if this has already been sugested, havent
really been paying attention)
This works too… but you still have the same overlapping issues.
If you have a sprite behind another sprite… and one of them moves… you
still have to search for all sprites affected by overlapping and blit
them.–
Brian
why not just keep the whole background somewere else and blit from it only
the parts that were changed? (sorry if this has already been sugested, havent
really been paying attention)
Phoenix Kokido wrote:> surface…
Date: Sun, 27 Feb 2000 14:06:41 +0000
Content-Type: text/plain; charset=“iso-8859-1”
The easiest thing to do is create another surface (either use
SDL_CreateRGBSurface, or load your bitmap into another surface) and
before you blit your bitmap to the display, blit the portion of the
display under it to the second surface. Before you move the sprite,
but after you display it on the screen, redraw the part of the
background you saved on top of your bitmap. Lather, Rinse, and
Repeat.
This should never be a problem if you erase them in reverse of the
order that you drew them in the first place.
ex.
Save Background Draw Sprite 1
Save BG, Draw Sprite 2
Save BG, Draw Sprite 3
Update Display
Erase Sprite 3
Erase Sprite 2
Erase Sprite 1
Repeat
It is still an issue because your “save under” code must be much more
complicated.
Think about this:
sprite1 appears
sprite2 appears in front of sprite one(Saving backgrnd w/sprite1 in
it)
now sprite1 leaves.
You have to update sprite2’s background because sprite1 has left and
thus
changed the pixels behind sprite2.
Thats the point I was making. It is an issue because you have to add
more
complication and you can’t just set a background for a sprite only
when
that sprite moves. When any sprite moves, you have to update the
save-under for all sprites above it.
It’s just more complicated than a simple… “save under” on a
per-sprite
basis.
Brian
It brings the question which is faster/more efficent, saving the
backgrounds or just redrawing all the sprites on a copy of the
background in memory and bliting it to video memory. I’m pretty sure
that redrawing it all would be more efficent and faster. There also is
the method of creating difference maps using xor,and,nor’s and such but
I’ll have to check one of my reference books for the exact sequence
that it needs to be done.=====
Jason Platt.
“In theory: theory and practice are the same.
In practice: they arn’t.”
ICQ# 1546328
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
It all depends on your application. Lots of sprites may mean it’s quicker
to redraw. Just a few moving sprites is probably quicker to do this way.
Under Linux, you won’t have the benefit of direct video memory access
until DGA 2.
When you get to the optimize phase of your game development, you’ll want
to try out different methods in a “realistic world” and figure out what
works best for you. Do several simulations and figure out what works best
for you.
I’ve been told by some successful game developers that wasting too much
time optimizing your code up front is a bad idea. Write code fast, not
fast code. Optimize the bottlenecks later, don’t optimize every section
of your code right now. You’ll never get anything accomplished.
This doesn’t necessarily mean do stupid things you know you’ll have to
change later though…–
Brian
It brings the question which is faster/more efficent, saving the
backgrounds or just redrawing all the sprites on a copy of the
background in memory and bliting it to video memory. I’m pretty sure
that redrawing it all would be more efficent and faster. There also is
the method of creating difference maps using xor,and,nor’s and such but
I’ll have to check one of my reference books for the exact sequence
that it needs to be done.
=====
Jason Platt.
“In theory: theory and practice are the same.
In practice: they arn’t.”
ICQ# 1546328
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com