Re: [pygame] Images V Sprites

[Phil Hassey <philhassey@xxxxxxxxx>]

Most of what James is suggesting can be found in
pgu.tilevid.Tilevid -- see
http://www.imitationpickles.org/pgu/

Check out the examples/tilevid*.py

Phil

--- James Hofmann <jwhinfinity@xxxxxxxxx> wrote:

> 
> 
> --- 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
> 



	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/