Hi Pharan,

Perhaps somebody could guide me, I have some better screenshots to better explain what I'm trying to solve.

Here is what I see when I have premultiply alpha set to true. renderer.setPremultipliedAlpha(true)

As Pharan said, some things do look better with premultiply alpha set to true, namely, the arrows are much easier to see this way.
However, the bow, which uses a FFD mesh, as you can see, is streaky and weird looking.

With premultiplied alpha set to false, the bow looks much better all around.

Does anybody have any recommendations? It doesn't seem like I can easily set only the bow to pma false and the rest of the skeleton true.

Best,
Nick

Oh, and I should mention 2 other things, in the editor everything looks perfect, not even any pixelation. I've also got the scale set to 0.25, so the image in the game is smaller, so that could be part of the issue.

Yeah, this is rather tricky... I believe you and I agree that when you run an animation in reverse, the animation should be the reverse of what it was forward. The place where it breaks down is "what is the state before the first keyframe?" In my use cases the state of the attachment before the first keyframe is always what it was in the setup pose, but I get that going to the setup pose won't work for everybody.

There's another problem that's somewhat related. In ColorTimeline#apply there's the line "if (time < frames[0]) return;" which makes it so when playing an animation in reverse, the color doesn't end up on exactly what it was at frames[0]. This is particularly noticeable for alpha tweens.

Ok, I think I figured out a disconnect we were having. Having a frame at time 0 for attachments didn't solve my problem because of this oddity:

If you play an animation forwards, in order to hit frame 0 correctly you need to do: from: < 0, to: > 0
If you play an animation backwards, in order to hit frame 0 you need to do: from > 0, to: == 0

I just updated Spine to the 2.0.02, and now it won't export unless I freshly put in the export path.
That is, I paste the export path, export, works
try to export again, nothing.

Update: It is exporting, just to the wrong location.

My path is like this:
Source: MyGame\gfx\Game\Characters\humanoid.spine
Export: MyGame\Android\assets_unpacked\game\skeletons

Instead of exporting to that destination it exports to:
MyGame\gfx\Android\assets_unpacked\game\skeletons

It's feels like it's now doing relative path exporting (which is good), but missing a ../

So if I'm understanding correctly, you recommend to never have something detached in setup pose and for every animation at time 0 detach everything unused?

It sounds like it might make more sense to me to attach equipment only via code.

Setting a key at the start of the animation doesn't solve my problem.

To try to explain it in a different way. The behavior I'd expect is that for any type of animation, if I play it in reverse, it should match exactly what it was forward, but in reverse order.

So if I add an attachment at frame 5, if I play the animation in reverse, I would expect the attachment I added on frame 5 to be removed when reaching < 5.
That is what I see in Spine, but not what I see in LibGDX (without my monkey patch).

Why do you say that if time < frames[0] shouldn't set the attachment to null?
Let's say that in setup I have a sword, but I have it marked as hidden. Then I have a sword swing animation, and on frames[0] I attach this sword (or any other frame for that matter). If I play this animation forward, then play it in reverse, I would expect the sword to no longer be attached at the end of the reverse animation. It should be exactly as it was before I played the animation forward.

-Nick

The purple body is supposed to be #A6A6A6FF
The asset is white, and the Region in Spine (setup mode) is set to a gray tint.

If I click around it switches from purple to gray.

I never saw the issue before 1.9.15
I haven't tried .18 yet

:-) I want Spine to replace everything I previously used the Flash IDE for. Although it's ok if I need a separate tool to draw the graphics as long as the workflow is smooth (which it is).

I've been using LibGDX to make my game for a few months now, and to describe what "All the things" are, I need to describe where the rough spots are in my workflow.

I chose LibGDX over Unity because I like the runtime better, I prefer how light-weight it is, my game is 2d (Unity2d is newish), and I prefer the workflow of IntelliJ/Java over Unity/C# (or VS).
However, Unity tooling is pretty awesome for configuration. You can use the Unity editor to setup your level, configure everything visually, and even write editor extensions. This is something I feel like I'm missing with LibGDX.

Spine is a skeletal animation tool, and as far as that goes, it's the best I've seen. I would just love to see the same style of lightweight tooling around frame animation, and tooling around visually setting up and configuring my components. Adobe has made several crappy attempts at this: Flash Component inspector, Flex Design view, Adobe Catalyst. Unity is tied to the Unity runtime, but I might play around with it to see if I can write my own exporters.

Nate, you are my 5th favorite person in the whole world, I just wanted you to know that.

Yeah, but that's not very smooth because you need to put in a ton of keyframes for a basic curve. Sometimes I can get the effect I want by making a parent bone ease one way and the child bone ease another, but this setup isn't always ideal.

Is there any way to do a motion guide currently?

For example, if I want to animate a ball bouncing, I'm not sure what the best way to do this is without being able to draw a path the ball moves along.

Thanks for the response. I've looked over the attachment timeline code and it makes sense now how it all works under the hood. Starting at -1 makes sense, but somewhat related, I did submit a bug in the bugs forum about playing a timeline in reverse.

NVidia Quadro K2000M
It's not a huge deal, just super weird. It's like it has its color set to purple, then when I click around a bit it turns back to gray. I never saw this happen before the patch, if that helps at all.

When I first open Spine in 1.9.15, some of the assets appear as purple until I do a bunch of stuff. It might be trying to tell me that my dudes would look better purple, and maybe it's right.

If I have a keyframe to attach a slot, reversing the animation will not detach the slot.
With the previous version of the libgdx runtime, I could add a keyframe to detach the slot, and that would work, but with the latest version the slot never detaches.

I don't know if I'm awake enough to do a pull request just now, but here's what seems to fix my problems:

Animation.java Line 505 in AttachTimeline

public void apply (Skeleton skeleton, float lastTime, float time, Array<Event> events, float alpha) {
         float[] frames = this.frames;
         if (time < frames[0]) {
            skeleton.slots.get(slotIndex).setAttachment(null);
            return;
         }

     int frameIndex = time >= frames[frames.length - 1] ? frames.length - 1 : binarySearch(frames, time) - 1;

     if (lastTime <= time) {
        if (frames[frameIndex] <= lastTime) return; // no-op
     } else {
        if (frames[frameIndex] >= lastTime) return; // no-op
     }
     String attachmentName = attachmentNames[frameIndex];

     skeleton.slots.get(slotIndex).setAttachment(
        attachmentName == null ? null : skeleton.getAttachment(slotIndex, attachmentName));
  }

Hi all,

I am not entirely sure if this is a bug or if there is something I'm misunderstanding.

I just updated to the latest version of Spine, and the latest version of the Spine libgdx runtime, and now if I have a slot attachment at time 0.00, if I do the following:

myAnim.mix(skeleton, 0, time ...

The attachment doesn't show up, I need to do this instead:

myAnim.mix(skeleton, -0.01f, time ...

What's the standard practice here? For my animations I've been using the convention:

t = 0

update(dT) {
nextTime = t + dT
anim.mix(skel, t, nextTime);
t = nextTime;
}

Is that the right way to do it? After the update I had to change t = 0 to t = -0.01f