OK. I definately have animation upon an action each time, but i think i am somewhat confused on the process of auto animation. Being: hitting a key press and iterate through images at a specified time delay.

So my little project for figuring this out was to chop the sprite sheet, splice the sheet to use the wooden door only. Then upon spacebar press, animate through those 4 images to open, then spacebar again pressed to animate the door to close.

I dont really get the concept to say, this is the start time of the whole animation, then keep looping through the mainloop but iterate through these images with some delay, not upon each iteration of the loop

one thing that i dont understand about this code is when i look at it, it makes me think the way it is coded, it should only get executed the first time. To pinpoint what i mean, animate() gets run every time. if you hit spacebar ( IE self.start_anim), then it gets the difference (Ie diff), and if that difference is greater or equal to than self.delay... then increment/decrement the frames. This makes sense to me as run the first time, but the next time ran ( the next time looping), i dont see where it would execute self.next.frame as it also resets self.timer too that previous new time, making the new difference less and not executing the if condition:

The timer only updates if the inequality is true. If the diff is not greater than the delay the timer doesn`t change.The current frame gets drawn no matter what. Once the diff is greater than delay then the frame count is incremented/decremented thus changing the current frame.When the frame is changed we update the timer so it won`t change again till the diff is again greater than the delay. Throw some print statements around to see what is happening.

wow ok, i redid it again, and it took me like an hour to figure out that i forgot the clock.tick() and i was not reassiging the timer because of a typo, lol.

OK i think i got the animation process. I also made a function to just reuse extract_frames(), just because i got sick of rewriting the code to extract the frames of a given sprite sheet. Which i might now just put as a Control() method from now on. I removed itertools and used a nested for loop, because i normally dont like importing if i dont have to, but does itertools.product() return the result faster than a nested for loop, because then it might suit well based on a somehwat large game loading a ton of images, would make sense.

I am going as slow as a turtle figuring this all out, lol, but whatever at least i am getting somewhere.

def extract_frames(sheet, row_image_amt, col_image_amt): '''extract frames from sheet based on number of images of row and col''' frame_inds = [] for row in range(row_image_amt): for col in range(col_image_amt): frame_inds.append((row,col))

In this case I wouldn't worry about the performance of a nested loop versus itertools.product. The time it takes to do either of these should be negligible compared to the actual subsurface assignment. I would concern yourself much more with only passing the coordinates you need to your chop-into subsurface function. Previously I have had such badly arranged sprite sheets that I just input the coordinates needed manually. Even this is fine, if a bit tedious.

My biggest sprite project (the Cabbage game) although currently slated for recoding from the ground-up, demonstrated to me how hard it was to make a generalized sprite sheet. Some of my monsters needed to have images for all four directions, some for only two, and yet others only needed one. Some had death sequences that required numerous frames, while others just went poof. Some needed frames for special attacks while others simply hurt you upon contact. As nice as it would have been to have a single format on the sprite sheet this didn't end up being practical so I ended up using a lot of manually put in coordinates.

As long as you have a generalized function for getting the sprites off a sheet then who cares. As soon as you start having different sized sprites on a single sheet you may need to find a more generalized way than our current frame_coordinate method. Or you could make individual sheets always have a constant size. I personally favor the latter.

i havent made any images, nor know how to, so i have not even made a spritesheet yet. I have so far only used other peoples images and spritesheets. But it would seem plausible to organize the spritesheet accordingly, instead of looking like you dropped a bag of marbles and thats where the image gets placed on the sheet, lol.

but i have been using one person spritesheets that are organized, so i guess forgot about the people that just throw it on

wow cool. It does look close to 3d, but you can tell the axis is a little off. Well to me it looks a little off. Yeah once you get the hang of it, its quite simple, especially using the same code and modifying here and there.

I modified extract_frames() to go right to left then top to bottom, or to go top to bottom then right to left, depending on whichever spritesheet i end up getting

def extract_frames(sheet, row_image_amt, col_image_amt, left_right_first=True): '''extract frames from sheet based on number of images of row and col left_right_first if True: left to right, top to bottom, where if False: top to bottom, left to right ''' frame_inds = [] if left_right_first: for row in range(col_image_amt): for col in range(row_image_amt): frame_inds.append((col, row)) else: for row in range(row_image_amt): for col in range(col_image_amt): frame_inds.append((row, col))

There is however what appears to be quite a long waiting period to load though in that code. Also i tried changing the color on that spritesheet to ff00ff to set the colorkey to (255,0,255), but when i set the colorkey (code is commented out) i see what you mean when you get some pixels that apparently were not that color. So i just left the alpha layer on the image and used convert_alpha()

Well, that image is huge so doing it via urllib isn't really practical, but yeah. If you do it from a local file should work fine.

I do believe the creator of that sprite originally made it in blender, so technically it is a set of 3d frames put on a sprite sheet. Looks great in an asteroids game (I just hate not using custom art which really sucks as I'm a terrible artist).

lol, yeah the last time i tried to draw something for an animation for pygame, it was basically a stick figure animation walk. Ever since then, i just used other peoples images, and probably plan on doing so later for large games, just because i cant draw for crap.

I didnt even think of that. Run a blender script, and take screenshots of it circling, or whatever. Throw them on a spriteshhet for me to use in a game.

But yeah that image rotating looks awesome compared to some other asteroid games, just because of the 3d look to it

but i guess i would have to stick with sprtiesheets of 3d images for now, as 3d programming is still way out there for me. Havent even made a true game yet in 2d pygame.