Re: [pygame] Images V Sprites

[James Hofmann <jwhinfinity@xxxxxxxxx>]

--- Jason <jason@xxxxxxxxxxxxxxxxx> wrote:

> Last question for the night (it's far too late).
> 
> As a little exercise I'm going to create a small
> breakout clone.
> 
> I was wondering what the best approach would be for
> the blocks; would it 
> be a collection of images or sprites?

In the end, they're really the same, aren't they? One
way or the other you have to have collision detection
with rectangles. Doing it without sprites lets you
implement a more sophisticated collision
detection(that can take into account things like
bouncing), but for the simple case of hit/no-hit,
you're basically using rectangles, and there's little
difference there.

> I'd have thought for speed issues (and memory), the
> images would be far 
> better, but I haven't seen any details regarding
> collisions between 
> sprites and images. (BTW: talking of docs, nice work
> on the docs update 
> Peter).
> 
> I appreciate that for a breakout clone that there
> wouldn't be that many 
> blocks anyway, so you could "get away" with using
> sprites, but for 
> example having 3 balls bouncing around, say some
> nifty little special 
> effects like explosions etc, that all those sprites
> would gobble up much 
> needed resources.
> 
> Any thoughts on this?
> 

Run through what actually happens in both cases. With
sprites:

Each instance is going to do nothing in any given
frame unless it is hit. This means the impact of
having a new instance will be negligable on cpu time.
Memory-wise, you (should) be accessing the same loaded
image for all of them. So only position and object
instancing overhead are issues - and for a breakout
playfield this is still unimportant; Python can deal
with thousands of empty instances without trouble. As
a rule, the sound and image data will constitute most
of the memory used in a game unless you have a
GIGANTIC map or something.

So the advantage of implementing your own thing with
images, IMHO, would come down to whether you feel it's
better for the program structure. Sprites are dead
simple to drop in, but they can end up being annoying
to use for non-spritey things. So as far as learning
goes you want to try coming up with some of your own
collision at some point, and this is a good
opportunity.

I did in the past come up with a pretty sophisticated
sprite-and-tile collision system that would handle
things like very large sprites and bouncing and
corners well, and I want to dig that up and release it
someday(it's on a cd or something.....I hope :/ the
full engine had a lot of good stuff too, menus and
pathfinding and heavily abstracted gameplay objects
and a map editor...) but anyway, what I would do is
something like this:

-Make a list of lists (a 2d array) for the map of
blocks. You may want to make this an object with some
methods to simplify access later.
-The playfield is drawn once at startup; the most
memory-efficient approach would have the tiles around
the ball be redrawn from scratch each frame, but with
the RenderUpdates group you can save sanity instead
and have a copy of the full background with no ball
waiting in memory all the time.
-When the ball moves, it figures out where it is going
in its current vector.
-Check the tile located in the new ball position. If
it overlaps, the ball bounces and that tile is hit and
the image is overwritten there. Consider whether
you're going for the ball as a rectangle(check the
four corners - which assumes the ball is smaller than
any tile; for large objects you have to start
including more points to check), a pixel-perfect
approach(I've never done this), or just using the
center point(easiest).

That pretty much covers it, I think.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com