Lazrhog wrote

You have slightly dark lines around all your sprites, where the alpha blending is not working. When you make your Texture Atlas, you need to have pre-multiplied alpha and use the correct blending mode

(see my other thread for a before and after image where I had to correct it)

Ahh.... Yeah, I don't think Pygame supports all of the necessary blending modes, but I'll look at that stuff once I have my animation working properly. Thanks for the heads up.

The Python animation bugs I've been chasing have finally been squashed.

http://youtu.be/On242LJ0Olo

The issue was that when you apply a rotation to an image in Pygame (maybe this is true always?) the image's width and height change, so for a system where the x, y of the image is the top-left corner, you have to subtract (width / 2, height / 2) AFTER performing the transformation.

I was applying those prior to transforming, so the images were off by a bit, and what a pain to track down!

I have the dragon example running. There were some Atlas loading problems that would prevent atlases with more than 1 sprite sheet to fail to load.

I also fixed some bugs related to importing skeleton data and animation when certain keys were missing from the JSON files.

The latest code is up on github, and pypi.python.org.

Nate wrote

Haha rotation is a little messed up, but nice sword!

If your game toolkit can't draw quadrilaterals, then you should only use uniform scaling (equal x and y) in Spine. This is the case with Corona. You can actually use non-uniform scaling even if the game toolkit can't draw quads, but you have to align your images with the bone so that the images don't get squashed to a rhomboid (diamond) shape when the bone is scaled non-uniformly.

Ok, I'm ready to tackle this.

I can scale by integer values for both x, and y, but I can't scale the x and y separately with floats.

I can scale equal x and y with floats.

What's the best way to implement this? The images have float-value scaleX/scaleY, so it isn't apparent to me how to make this work, given the APIs I have available to me.

Here's the pygame documentation on transformations, for reference... maybe there's something in there that I'm not seeing.

http://www.pygame.org/docs/ref/transform.html

rotozoom will take a single scale value (float).

scale, and smoothscale will take an integer for the width/height of the new image, but not float.

Ahhh... duh.

Since scale and smoothscale take width, height I can multiply the scale by those...

Looks like I got it working.

Hrm... any idea why my spineboy is so stiff looking?

I exported these straight from Spine, so it's the latest example.

http://www.youtube.com/watch?v=4S3wCtJ711o

Yeah, I did that...

I stepped through with spacebar incrementing the animation time by 1 each time, and it sort of looks like his arm gets to key frame 20, and then snaps back to key frame 0 (or 32?), but that doesn't make sense to me.

I got mixing working:

There are still a couple of bugs... but the major features are present! :love: :beer: :party:

http://www.youtube.com/watch?v=nHHDglon6jk

I finally fixed the last rendering issue with spine-python.

The latest bits are up on github/pypi.