Interesting... something to do with setToBindPose()

Check this out!

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster

terrymisu yazdı

Interesting... something to do with setToBindPose()

Check this out!

HTTPS desteği olmadığı için görsel kaldırıldı. | Yine de Göster

Ok, but now it's not animating... grrr so close!

If I call skeleton.updateWorldTransform() once outside of my while loop but not inside the while loop, the skeleton draws properly. This works even if I don't call skeleton.setToBindPose() anywhere.

If I call skeleton.updateWorldTransform() inside my while loop, things don't draw properly.

Any thoughts as to what might be causing this? A timeline issue perhaps?

Here's the code that draws the initial pose correctly:

#!/usr/bin/env python                                                                                                                                                                                       

import os

import pygame

import pyguts as spine

if __name__ == '__main__':
    pygame.init()

width, height = (640, 480)

screen = pygame.display.set_mode((width, height))
screen.fill((0,0,0))
caption = 'PyGuts - A Pygame front-end based on the python-spine Runtime'
pygame.display.set_caption(caption, 'Spine Runtime')

atlasFile = os.path.realpath('./data/spineboy.atlas')
atlas = spine.Atlas(file=atlasFile)

skeletonJson = spine.SkeletonJson(spine.AtlasAttachmentLoader(atlas))

skeletonFile = os.path.realpath('./data/spineboy-skeleton.json')
skeletonData = skeletonJson.readSkeletonData(skeletonFile)

animationFile = os.path.realpath('./data/spineboy-walk.json')
animation = skeletonJson.readAnimation(file=animationFile,
                                       skeletonData=skeletonData)

skeleton = spine.Skeleton(skeletonData=skeletonData)
skeleton.debug = True

skeleton.x = 320
skeleton.y = 400
skeleton.flipX = False
skeleton.flipY = False
skeleton.updateWorldTransform()

clock = pygame.time.Clock()
animationTime = 0.0

done = False

while not done:
    clock.tick(0)
    animationTime += clock.get_time() / 1000.0
    animation.apply(skeleton=skeleton,
                    time=animationTime,
                    loop=True)
    screen.fill((0, 0, 0))
    skeleton.draw(screen, 0)
    pygame.display.set_caption('%s  %.2f' % (caption, clock.get_fps()), 'Spine Runtime')
    pygame.display.flip()
pygame.quit()

Lazrhog yazdı

you have the same aliasing issue I had to start with too.

I'm not sure what that means.

Lazrhog yazdı

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

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.

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

Nate yazdı

Something is wrong with your rotation. The arm shouldn't snap around like that. Note sure exactly what it could be...

Ok, I've finally dug into this a bit more.

I think that less than 30 frames of my animation are being drawn, but I'm not sure why.

I've got an animation with 120 frames. Only part of the animation ever draws with the Python, so this is what made me start thinking that this bug may be related to the # of frames.

Sure enough, I can cause a snapping arm movement with Spineboy by looping @ < 30 FPS.

Here's what my sword example should look like:

http://youtu.be/06wn68e0D7M

Here's what it actually looks like:

http://youtu.be/mKPTzDb4P8g

Seems like it might be timeline related, or maybe it's an issue with the values I'm passing to apply? What do you think?

[Edit] In case it's not obvious, the Spine recording wasn't playing from frame 0, but I recorded enough of the video playing for you to see the animation start over @ 0... sorry about that.

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

The latest bits are up on github/pypi.