Interesting... something to do with setToBindPose()
Check this out!
Loading Image
Interesting... something to do with setToBindPose()
Check this out!
Loading Image
terrymisu escreveuInteresting... something to do with setToBindPose()
Check this out!
Loading Image
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()
you have the same aliasing issue I had to start with too.
Lazrhog escreveuyou have the same aliasing issue I had to start with too.
I'm not sure what that means.
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)
Lazrhog escreveuYou 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.
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 escreveuHaha 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.
Instead of using the correct time difference for the animation. Put a really small number in so you can see where it is going wrong in more detail
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:
Something is wrong with your rotation. The arm shouldn't snap around like that. Note sure exactly what it could be...
Nate escreveuSomething 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:
Here's what it actually looks like:
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.