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.

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.

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.

Изображение удалено из-за отсутствия поддержки HTTPS. | Показать

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}

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?

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?

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?

Awesome... I'll do that then.

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!

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?

Изображение удалено из-за отсутствия поддержки HTTPS. | Показать

Shiu написал

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.

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!

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!