- Editado
Scaling Bug
I'm seeing some odd behavior with scaling in the runtime (spine-sfml). I have a 40 frame animation with 5 keyframes that just alternates scale from 0.95 and 1.05 on both axes. This works perfectly in the editor and in the runtime - but only when the root node is rotated away from 0 degrees. If it's exactly 0 I get something that looks like the animation is only updating once or twice per second. Rotation and translation both work fine.
Attached my skeleton. I was able to reproduce the problem using the vine example project.
Does it happen in the editor? If so, please post a project file showing the problem. I imported your JSON and it was fine at any root bone rotation.
Does it happen in the Skeleton Viewer? This uses the reference runtime implementation and can help determine if the problem is specific to spine-c or spine-sfml.
Skeleton Viewer
I worded that ambiguously. It works fine in the editor at any rotation. With the spine-sfml runtime though, it only works if rotation != 0. I just tried it in the skeleton viewer and looks fine there as well.
Thanks. Sounds like a spine-c or spine-sfml bug, we'll check it out ASAP.
Thanks!
And I now see there's a separate forum for bug reports. Woops.
Which forum doesn't matter much, since most of us use the "unread messages" view:
search.php?search_id=unreadposts#topics
I've opened an issue for this bug here [c][sfml] Scaling is broken when root bone rotation != 0 · Issue #664 · EsotericSoftware/spine-runtimes · GitHub
You said the problem is visible in the vine sample as well. I've tried this, giving the root bone a rotation of 0 at runtime. I did not see any issues.
Could you provide a full export of your skeleton including images? You can also send them via e-mail to contact at esotericsoftware dot com if you don't want to share it publicly.
OK, I was kind of able to reproduce the issue with the vine sample. I set scaleX/scaleY != 1 on the root bone. The vine animation then appears to start later than without root bone scaling. Adjusting the root bone rotation to != 0 does not fix the issue in that case though. It's actually only an issue if I set scaleY on the root bone O_o
The smaller scaleY, the longer the initial delay before the animation starts. Seems to be related to paths.
Could you please confirm that this is the issue you see?
OK, I can reproduce this with the reference runtime as well. It indeed seems to be related to paths. I'll have Nate look into this
That does sound like what I was seeing!
I attached the full project this time. And here's the slightly modified vine example I used to test:
void test_spine(const char* atlas_file, const char* skeleton_file, const char* animation_name)
{
// Load atlas, skeleton, and animations.
spAtlas* atlas = spAtlas_createFromFile(atlas_file, 0);
spSkeletonJson* json = spSkeletonJson_create(atlas);
json->scale = 0.5f;
spSkeletonData *skeletonData = spSkeletonJson_readSkeletonDataFile(json, skeleton_file);
if (!skeletonData) {
printf("Error: %s\n", json->error);
exit(0);
}
spSkeletonJson_dispose(json);
SkeletonDrawable* drawable = new SkeletonDrawable(skeletonData);
drawable->timeScale = 1;
spSkeleton* skeleton = drawable->skeleton;
skeleton->x = 320;
skeleton->y = 590;
spSkeleton_updateWorldTransform(skeleton);
spAnimationState_setAnimationByName(drawable->state, 0, animation_name, true);
sf::RenderWindow window(sf::VideoMode(640, 640), "Spine SFML - test");
window.setFramerateLimit(60);
sf::Event event;
sf::Clock deltaClock;
while (window.isOpen()) {
while (window.pollEvent(event))
if (event.type == sf::Event::Closed) window.close();
float dt = deltaClock.getElapsedTime().asSeconds();
deltaClock.restart();
drawable->OnUpdate(dt);
window.clear();
window.draw(*drawable);
window.display();
}
spSkeletonData_dispose(skeletonData);
spAtlas_dispose(atlas);
}
test_spine("Hero/Hero.atlas", "Hero/Hero.json", "Idle");
I also tried modifying the test code to rotate the root bone away from 0 to confirm the problem went away and it did not - like you saw. But if I do the same thing in my actual project then it does go away... I'll try to see if I can figure out what else is happening - maybe the ordering is different.
Also, completely unrelated, the spine-c runtime is by far the nicest library code I've ever seen. And it's not even your reference implementation! It's as simple as it can be and well organized so I can actually follow the data flow without needing to understand every part of it. And it's not abusing the heck out of the heap like everything else I try to use. You guys are heroes <3 Please make more stuff.
I guess I just wasn't rotating it far enough. If I add
skeleton->root->rotation = 5.0f;
after setting x, y then the animation appears to play correctly.
This issue hard to work on without knowing exactly what the incorrect behavior is. We decided there isn't actually an issue to be had, please see the issue badlogic posted above and we can continue discussion there.
Thanks for the kind words. I have mixed feelings about spine-c. The OOP allows us to keep the code similar to other runtimes, but implementing our own OOP in C makes me die a little inside. It's workable, but awkward.