[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Odd problem with lists



Right on, man.  In my case,  I can't think of any reason to have
dynamic animation lists.  I figure that it's better for my program to
load up a list of cels during initialization than to do any
manipulation during the actual game.


On Wed, 15 Dec 2004 00:35:35 -0500, Matt Bailey <mattb@xxxxxxxxxx> wrote:
> 
> 
> andrew baker wrote:
> >
> > What the heck are you doing copying images during your animation?
> > Forget that, it's wasteful and overcomplicated.
> 
>         No no no...........that's just for testing. It's the main reason I want
> my other method to work. :P Some folks in the chat room straightened me
> out on copying lists. Now I'm just doing "self.ladder_imgs =
> list(images.player_ladder_imgs)". So all I had to do was encapsulate the
> original list reference into the "list()" function. :)
> 
> > 1.  Make a list of images.
> > 2. For each animation sequence (for example walking_left and
> > walking_right), make a list or tuple of indices in your list of images
> > (i.e. walking_left=(0,1,2,3)) that correspond to the cels in that
> > animation.
> > 3.When the character state is (for example, walking to the left), then
> > anim_loop = walking_left.
> > 4.You have a loop that every few cycles increments the animation
> > counter.  Then player.image = anim_loop[animation_counter]
> <snip
> 
>         Thanks for the tips........I've never done lists of indices but I think
> I follow you. For now I'm sticking with the per-animation list idea. I'm
> quite a programming noob actually, and this method is very "friendly"
> and easy to work with. :) Plus it's a cinch to add or remove as many
> frames per animation as I need, all I have to do is add/remove the frame
> in the list.
>         Actually if you saw my whole code there would probably be a lot of "Why
> are you doing that..........." :) I just need practice. But I must say,
> I'm happy with the way things are turning out thus far. With enough time
> and tweaking, stuff works, and so far it's working pretty well. I'm able
> to tack new features/behaviors onto my player, for instance, without
> having to look over my old code again very much, and without having to
> redesign old behavior.
>         This is FUN! :)
> 
>         -Matt Bailey
> 


-- 
Andrew Ulysses Baker
"failrate"