Esoteric Software

[terrymisu]

I'm using the CPP runtime as my basis, and I'm trying to keep it as OS agnostic and Pythonic as possible.

If anyone's interested let me know.

[terrymisu]

O.o writing a runtime from scratch is a lot of work!

Kudos to Nate though, the code is clean.

I'm making good progress on the Python runtime.

[zeeknow]

Good luck with this. It would be great to have this functionality.

[terrymisu]

I've successfully coded up skeleton parsing and I'm working on the atlas parser right now.

I've still got a long way to go, but here's a taste.

[Nate]

Nice!

[terrymisu]

Atlas code is written.

{'filter': ['Nearest', 'Nearest'],
'format': 'RGBA8888',
'name': 'data/spineboy.png',
'repeat': 'none'}
{'format': 'RGBA8888',
'magFilter': 'Nearest',
'minFilter': 'Nearest',
'name': None,
'texture': <Surface(256x256x32 SW)>,
'uWrap': None,
'vWrap': None}
{'index': '-1',
'name': 'head',
'offset': [0, 0],
'orig': [121, 132],
'rotate': 'false',
'size': [121, 132],
'xy': [1, 122]}
{'flip': False,
'height': 132,
'index': -1,
'name': 'head',
'offsetX': 0,
'offsetY': 0,
'originalHeight': 132,
'originalWidth': 121,
'pads': [],
'page': <pyguts.Atlas.AtlasPage object at 0x1034f0390>,
'rotate': False,
'splits': [],
'width': 121,
'x': 1,
'y': 122}

[terrymisu]

I pretty much have everything except the animation and timeline classes working... I think.

Here's a video of my runtime running with a delay so you can see each texture draw.

Generically, it's python-spine, but I'm calling the pygame runtime "PyGuts".

PyGuts Video

Nate - Would you be willing to host the runtime, or would you rather I set up a separate Github repository?

[Nate]

Cool!

FWIW, I would call it spine-python to match the others.

Hmm, not sure who should host it. Maybe I should only host the runtimes that I'm maintaining? I don't really have the bandwidth to dig into Python stuff, unfortunately. I can link to you on the Spine github repo page.

[terrymisu]

Hi Nate,

My plan was to call the project spine-python (for instance, on Github), but I was going to call the pygame wrapper pyguts with the idea that other graphical front-ends for the spine-python runtime can be distinguished easier.

So users of python-spine with pygame who want to install the runtime would know they can:

easy_install/pip install pyguts

for the PyGame version of the runtime.

Python allows us to do:

import pyguts as spine

So any future frontends would

import foo as spine

as well, and all they really have to do is make a copy of the module, change its name, and modify the blitting/texture handling code, and any code other people have written will Just Work™.

Are you ok with this approach?

[terrymisu]

We might be able to separate this into two modules so that there aren't dissimilar copies of the spine runtime embedded in different toolkits.

Right now I've got pyguts/spine, but I can pull that out and we can call it "python-spine". So I'd have pyguts import python-spine inside of itself.

That's probably a better solution.

I'll still need the pyguts module for PyGame, though, so that'll work.

Thoughts?

[Nate]

Right now I've got pyguts/spine, but I can pull that out and we can call it "python-spine". So I'd have pyguts import python-spine inside of itself.

That sounds good.

[terrymisu]

Awesome... I'll do that then.

[terrymisu]

Ok, I have the Animation and timeline stuff done, but I'm running into some problems.

I have no idea how to properly draw a skeleton.

It feels like I'm close to having this working... but I'm confused about how things are bolted together and which set of coordinates I should be using to draw with.

Here's the code I'm using in my main application:

skeleton.flipX = False
skeleton.flipY = False
skeleton.setToBindPose()
skeleton.getRootBone().x = 200.0
skeleton.getRootBone().y = 420.0
skeleton.updateWorldTransform()

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

while True:
deltaClock.tick_busy_loop(60)
for event in pygame.event.get():
if event.type == pygame.QUIT:
sys.exit()
screen.fill((0,0,0))

animationTime += deltaClock.get_time()

animation.apply(skeleton=skeleton,
time=animationTime,
loop=True)
skeleton.updateWorldTransform()
skeleton.draw(screen, 0)
pygame.display.flip()

And here's the code I'm using in my skeleton.draw() routine:

def draw(self, screen, states):
for slot in self.slots:
if slot.attachment:
slot.attachment.draw(slot)
screen.blit(slot.attachment.texture, (slot.attachment.u2, slot.attachment.v2))

I know that I still need to apply rotation and scaling, but Spineboy's head isn't even landing in the right spot, so I feel like I'm doing something very wrong.

Thanks!

[Nate]

It won't work right until you get everything just perfect. It can be a pain.

Are your coordinates y-up or y-down? IIRC, libgdx is y-up, Corona is y-down.

The u and v are texture coordinates, I can't tell but maybe you are using them as vertex coordinates?

You need to draw the slot's image at the bone's (worldX, worldY) + (the image's attachment offset rotated by the bone's world rotation matrix). See here:
https://github.com/EsotericSoftware/spi ... .java#L132
Also see updateOffset(), same file. The 4 vertices of the image are precalculated so they only have to be rotated.

If you can only draw rectangles and not quads then you can look at how the Corona runtime draws. Note that you should not use non-uniform scaling (meaning x and y are scaled different amounts) in Spine if you can only draw rectangles. To see why, attach an image to a bone, rotated 45 degrees relative to the bone, then scale the bone non-uniformly and notice how the image becomes a diamond shape.

[terrymisu]

The pygame coordinates are y-down (top left of the screen is 0,0), and I think it can only draw rectangles.

I tried the Corona code, but no luck yet. I'm getting closer... the up and down motion is correct. I was seeing that when just using bone.worldX/bone.worldY, too.

He's "walking" but his body parts are all in the wrong places.

Any other suggestions for debugging this?

[Nate]

Mmm, not really. It's one of the trickiest parts. It's hard because it's either completely FUBAR or it works correctly. You'll get some nice satisfaction when it works. Good luck!

[Søren]

If you can show debug of where the root position is it might be easier. Are you taking relative position into account here ?

[terrymisu]

If you can show debug of where the root position is it might be easier. Are you taking relative position into account here ?

So, when I change the root bone position, my images do get drawn in a different spot with the same messed up positioning, so that would seem to indicate that the root bone is being referred to in some manner.

When you say relative position, what exactly do you mean? What relative to what?

I'm a little out of my depth as far as understanding exactly what needs to happen. Nate's explanation was a good one, so I think there are still a few things to try.

I noticed some debug code in Corona for helping figure out bone placements, so I'll code that up in Python and see what it gives me.

[terrymisu]

Mmm, not really. It's one of the trickiest parts. It's hard because it's either completely FUBAR or it works correctly. You'll get some nice satisfaction when it works. Good luck!

Hah yeah, well the image placement is obviously jacked up, but what I meant was that when the animation runs, the parts all bob up and down in a manner that definitely looks like the walk animation. They're just all in the wrong spot.

Thanks for the encouragement, and all of your help so far!

[evs]

@terrymisu

Are your graphics anchor points set to the centre in Python?

I ask because when I ported the Corona Lua to Gideros my graphics were out
of kilter (and bobbing) until I set the anchor points correctly


cheers

evs

[Søren]

I think you would find things a little easier to debug if you added a debug method to draw the bones, just indicate where the pivot is with a circle and the bone with a line. Then you'll know if it's the bones or the images that are causing the problem.

[terrymisu]

@terrymisu

Are your graphics anchor points set to the centre in Python?

I ask because when I ported the Corona Lua to Gideros my graphics were out
of kilter (and bobbing) until I set the anchor points correctly


cheers

evs

No, they're not. Pygame draws surfaces at (0, 0) by default.

Sounds like that may be the culprit... I'll give it a shot. Thanks!

What exactly did you have to do to fix this for Gideros?

[terrymisu]

I think you would find things a little easier to debug if you added a debug method to draw the bones, just indicate where the pivot is with a circle and the bone with a line. Then you'll know if it's the bones or the images that are causing the problem.

Does my debug look correct? I can't quite tell, but it looks as though the images are off?

The top most circles look like the proper head/eye placement?

Thoughts?

[terrymisu]

Let's try this again... the previous image was with flipX = False, flipY = False, and the root bone at 0, -300.

Here's one with flipY = True and the root bone at 0, 0:

[terrymisu]

Hmmm... Looking at the Corona runtime some more, I think that I'm completely missing some steps.

I'm not rotating or scaling in pygame. I guess I got confused about that because the corona runtime apparently handles it internally with the image.x, image.y, image.scaleX, image.scaleY, and image.rotation variables on the texture?

Also, do I need to skeleton.flipY, or skeleton.flipX, considering that pygame is rendering from 0, 0 as the top-left corner? Seems like I need to set flipY?

Here's my debug code, which I'm not sure is correct:

debug = True

if debug:
for bone in self.bones:
lineX = bone.worldX
lineY = bone.worldY
lineRotation = -bone.worldRotation

if self.flipX:
lineXScale = -1
lineRotation = -lineRotation
else:
boneXScale = 1
if self.flipY:
lineYScale = -1
lineRotation = -lineRotation
else:
boneYScale = 1

lineColor = pygame.Color(255, 0, 0, 0)

pygame.draw.line(screen, lineColor, (0, 0), (x, y), 1)

circleX = int(bone.worldX)
circleY = int(-bone.worldY)
circleColor = (0, 255, 0, 0)
pygame.draw.circle(screen, circleColor, (circleX, circleY), 5, 1)