itch.io

Well, the answer is a bit complicated.

Very old versions of the plugin didn't require any spritesheets. Instead the current frame would be injected at runtime as the texture of the mesh no matter what.

Now while inelegant this technically worked suprisingly well but as I came to realize ONLY in preview. Because when exported Construct uses a spritesheet itself and simply injecting the image, while fine in preview, would now result in a very faulty texture using the whole spritesheet for any frame basically.

In theory the workaround could be (I haven't actually applied it at any point) to read out the coordinates for the frames Construct creates and then use those to inject the current frame correctly again.

But in general injecting the frame at runtime isn't optimal and it's much cleaner to let Babylon.js have its spritesheet like it's designed to work.

Animations will still be set up and can be altered in the C2 editor in terms of animation and frame speed, loop settings and so on.

If you have what I would call a regular workflow for your graphics/animations creating them in an application like say Asesprite the only additional step is exporting the whole thing as spritesheet and adding it to your project.

Make sure your C2 animation order isn't different from the spritesheet (if idle animation is first those frames need to appear first in your spritesheet, then the frames of the second animation and so on) and it will work. Technically you can even use empty frames in the C2 editor and set it up like that.

So to summarize from my perspective it's the best solution to simply import a spritesheet which is trivial for most usual workflows. It avoids injecting frames at runtime which in itself might cause unforseen issues.

Let me know your thoughts.