C3 Spritesheet feature isn't true spritesheeting :(

I think there's some confusion over how the term "spritesheeting" is used. In our blog post, we meant the optimisation of combining many images in to fewer images, which has many benefits ranging from performance to download size. I think this thread is more about the process of importing and using spritesheets in Construct.

I don't think it's a good idea to give C3 an unmodified spritesheet and force it to use that. It's effectively a de-optimisation, because currently C3 is able to pack animation frames from a wide range of objects in to a single spritesheet, bringing greater performance benefits. Both C2 and C3 also do extra processing on the spritesheets it generates - for example often naive exactly-adjacent spritesheets have issues with color bleed between frames, especially when scaling them down. Construct does some extra processing like padding and repeating the outer rows of pixels to guarantee there won't be visual artefacts at runtime. If you use the spritesheet your artist sent you directly, it could actually cause these glitches, which we know from past experience users will immediately file bugs for. Also unless it adheres to various technical restrictions on power-of-two sizing, on some systems it could also display with different visual quality - again C3's spritesheeting algorithm is able to guarantee this won't happen. It's really quite a sophisticated pipeline with many non-obvious aspects. So I really think this is something the editor should be doing for you - it both improves performance and helps ensure the best visual fidelity.

As for importing updated spritesheets to better use them in C3, I'm sure we can make some simple changes to make that easier. It sounds like an "import spritesheet over existing frames" option which keeps all collision polys, image points etc. and just updates image content from a new spritesheet would do a lot to help. Does that sound like what you need?

This is a pretty nice feature. Currently I'm using sprites on different animations, and frames, so when I export I get spritesheets. So if I'm understanding this right it will have the benefits of tilemap object, but not restricted to power of two sizes?

Ashley

If by sprite sheet you mean a packed texture atlas and not simple animation strips then yeah, that would be a great help in my case at least. As long as we're able to import sprite frames from texture atlases outside C3 easily it doesn't matter if the ones C3 use internally are different.

Import from animation strips would also help if C3 was able to boundary crop each animation frame so we don't get a lot of wasted image space.

Not trying to be the party pooper here, but the competition allows both actually.. import an artist made sheet, define cuts and all and keep that structure for re-imports of updated artwork AND allow packing and output of an automatically optimized version of it or mixture with other atlases, depending on draw call optimizations etc, if the user so chooses.

That helps the noobs to avoid suboptimal sheets and at the same time allows more sophisticated pipelines things like using an external packer that might even be better than what the engine manufacturer has implemented

As for importing updated spritesheets to better use them in C3, I'm sure we can make some simple changes to make that easier. It sounds like an "import spritesheet over existing frames" option which keeps all collision polys, image points etc. and just updates image content from a new spritesheet would do a lot to help. Does that sound like what you need?

It would certainly be a step in the right direction, and help improve the process in my opinion.

Like Eisenhans mentions, it would be great to offer something more substantial, as the current method construct provides can be slow and cumbersome to work with if you have sprites with many animations and frames.

What I would envision is basically importing a spritesheet, and viewing the entire image in the editor, with tools to select frames from the sheet.. You could have the same UI, but instead of showing a single frame in the editor, it shows the whole sheet. If you add an animation, you can add frames in the same way, but adding frames draws a rectangle in the spritesheet that you can move around and adjust size. If you add an image point, it shows that as well depending on which frame you have selected.

The main thing here is that the whole sheet is shown in the editor, and the frames simply show a rectangle drawn over that sheet- and the collision poly and image points can show as well depending on the selected frame.

This wouldn't be that big of a change to implement in my opinion, because it would use the same UI essentially. The benefit here is that you can import/export one image, and work with one image in the editor or in an external paint editor- making the process more efficient.

What do you think about this Ashley ?

I think it would be very simple for you to implement as it uses the same UI, you might even be able to include a way to switch between modes. I suggest a way to switch as it would offer more flexibility, but If not, I suppose you could create a new object and call if Spritesheet, similar to how you have the 9patch.

The main thing here is that the whole sheet is shown in the editor

What's the benefit of that if you can import and export whole animations as spritesheets? That seems to solve the problem of managing art resources as spritesheets, but what's the purpose in showing a whole sheet? If you're going to modify the collision polygon for example, you can do that easily enough frame-by-frame, right?

What's the benefit of that if you can import and export whole animations as spritesheets?

Construct doesn't have exporting of spritesheets from the sprite editor. It only exports per frame, so you have to reassemble them in an external paint editor before doing further work to them, especially if you want to animate them in the external editor. So it becomes redundant work that takes away time.

Then you have to reassemble them into a form that can be reimported back into construct- more time taken away. And what happens if you add or remove frames in the process- there becomes inconsistencies.

That seems to solve the problem of managing art resources as spritesheets, but what's the purpose in showing a whole sheet? If you're going to modify the collision polygon for example, you can do that easily enough frame-by-frame, right?

Showing the whole spritesheet has many benefits:

+You can paint anywhere on it without flipping through frames/animations. This lowers the amount of times you must click and reposition the mouse- allowing work to be done more fluidly without pauses. You can apply changes to pixels/details across multiple frames this way more fluidly without swapping between tools/panels.

+If you show the whole sheet, you can rely on one image. So you can export that one image instead of clicking through each frame/animation exporting each one having to reassemble them all into something workable in an external editor.

+You can then reimport just one image, and still have all the frames/polygons/imagepoints still positioned on the sheet where you have assigned them previously. If you have added another frame somewhere in the sheet, or inserted a frame, you can include tools to drag/position those frames to their new locations(you can reposition the frame and it would reposition the corresponding imagepoints/poly relatively). You could just click a frame and drag it across the spritesheet to the new location- duplicate if necessary for new frames.

The frames would have a relative position to the spritesheet, and the imagepoints/poly would be relative to the frame.

Basically this way would lower the amount of redundancy involved, improving the workflow. It would also open up other possibilities, like applying effects across the entire sheet- like changing the color palette.

Also, it might open the possibility of exporting/importing to certain formats that spritesheet editors use.

>

> What's the benefit of that if you can import and export whole animations as spritesheets?

>

Construct doesn't have exporting of spritesheets from the sprite editor.

Yeah, I meant we could add that - so you can export and reimport as a spritesheet.

Yeah, I meant we could add that - so you can export and reimport as a spritesheet.

Yeah, but what happens if you add or remove frames, or whole animations? How does Construct interpret those changes?

If I export all the animations to one sheet. How do I import all the animations from a sheet.

How do I import a whole sprite sheet with multiple animations(not just frames), into the editor without any prior animation data existing?.. How do I tell construct which frames correspond to which animations in the spritesheet?

If I'm forced to split the sheet into multiple sheets per animation, it doesn't solve the issue.

You're saying all this can be done and still have imagepoints/polygons stay intact? frame speeds? loops settings?

Well, that's why going frame-by-frame also works well - it's unambiguous when you insert a new frame, you know exactly where it will go, or you can copy another frame including all its metadata like collision polys. If you work with spritesheets and add a new frame somewhere, it's not easily possible to tell what changed with the newly imported spritesheet - even if Construct kept animations as single spritesheets. Basically all it can see is it's got more or fewer frames, but it doesn't know where exactly they were added or removed, so where should it move the polys and image points and all that? So spritesheets may be useful as an import format but they don't seem so effective as a way to update existing animations - unless you do an "import the same frames over existing ones" type import.

Well, that's why going frame-by-frame also works well - it's unambiguous when you insert a new frame, you know exactly where it will go, or you can copy another frame including all its metadata like collision polys. If you work with spritesheets and add a new frame somewhere, it's not easily possible to tell what changed with the newly imported spritesheet

That's not true though- you must be seeing this in a way that makes you believe that the spritesheet format would be ambiguous. It doesn't have to be.

You could still create frame and animations in the same procedure as it is done currently, however it would simply place the frame over the spritesheet. You'd still have the frames displayed in the animation panel, and could reposition them(to determine the play order), select them, etc. When you select them, a box on the spritesheet would display to indicate where that frame is located on the spritesheet. If you select the animation in the animation list panel, all the boxes could display in the spritesheet, allowing you to easily see the correspondence.

The great thing about this method is you can make changes to the spritesheet with lesser impact on the corresponding frame data, because that data would remain in tact and can be adjusted independently. There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned). Or you could remove or add the frame data, even duplicate it. This would all be done independant of the actual spritesheet, so you can work with the spritesheet without effecting the frame/animation data.

At the moment the sprite image is tied to the data too closely- the spritesheet method allows more flexible workflow that is simpler and less of a hassle with working with many frames/animations. Most sprites have lots of frames and animations, so the spritesheet method I describe makes more sense.

My point is even if C3 does all of that, if you then try to import a spritesheet again with a new frame in the middle, how does it know to shunt along all the metadata of the frames after it? That's a tricky problem. However you seem to suggest that is unlikely...

There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned).

...in which case an "import sprite sheet and replace existing images" ought to cover the workflow of using spritesheets, right? Then the rest of the ideas sound like they're just a different way of presenting the same information.

My point is even if C3 does all of that, if you then try to import a spritesheet again with a new frame in the middle, how does it know to shunt along all the metadata of the frames after it? That's a tricky problem. However you seem to suggest that is unlikely...

> There would be no need to rebuild all the data because it would be already developed- you would simply shift the frames or animations, and all the data shifted(if the artist decides to reorganize the sheet, etc, which wouldn't happen often because the organization is usually planned).

>

My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.

Your proposed addition doesn't solve the issue of managing frame/animation data whenever the sprite animations are changed externally, because how would it know the correspondence with those changes.

In either your case or my case, it wouldn't be able to know the correct correspondences to all the potential changes. In my case however, the frame/animation data is independent and can remain present regardless of additions/subtractions from the spritesheet. This would allow flexibility in the workflow.

...in which case an "import sprite sheet and replace existing images" ought to cover the workflow of using spritesheets, right? Then the rest of the ideas sound like they're just a different way of presenting the same information.

But your proposed method can't determine correct correspondence to all potential changes to the spritesheet being imported. What if frames are reordered in the spritesheet, removed, added, changed, resized, etc. You proposed method wouldn't cover these cases.

However, my proposed method allows for this flexibility. Regardless of whatever changes are made to the spritesheet, the frame/animation data remains as defined by the user and can be adjusted manually for whichever changes they made to the spritesheet without having to recreate the data. Nothing is lost while the spritesheet is being developed- the animation/frame data can be modified to reflect the current designs of the spritesheet.

My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.

Based on what you wrote, I imagine a new window with the imported spritesheet displayed and coloured rectangles on top of it with the collision polygons to represent the frames. Then the user could drag and drop those rectangles to reorder them manually on the spritesheet while the frames would keep their data (collision polygons, image points, etc.). Is this what you're proposing?

>

> My point is that it wouldn't need to do that automatically. The user could manage that more efficiently if the frame/animation data is controllable independently of the spritesheet.

>

Based on what you wrote, I imagine a new window with the imported spritesheet displayed and coloured rectangles on top of it with the collision polygons to represent the frames. Then the user could drag and drop those rectangles to reorder them manually on the spritesheet while the frames would keep their data (collision polygons, image points, etc.). Is this what you're proposing?

Maybe- let me show some images of what it would be like just to be clear (I made these sprites by the way).. This is just a rough concept, but shows how the gui doesn't need to change at all.

In this first image, it shows all the boxes for the currently selected Animation in the animation list:

Also note how I've added a new tool on the toolbar- these new tools could be used to position/resize the boxes that define where the frames reference the spritesheet.

In the next one I show what happens when you select a frame from the frames list on the bottom:

You'd be able to position/resize it via new tool(s) on the left toolbar and the x,y,width,height inputs above.

Next I show how the polygon is displayed for the currently select frame when you have the polygon tool in use:

As you can see, the frame thumbnails in the frame list show the corresponding area on the spritesheet. None of the gui has changed. The main window shows the spritesheet.

And yes glerikud, if you reposition one of the boxes, it would reposition the corresponding imagepoints/polygons as well.

There could possibly also be a way to click a button to hide the rest of the spritesheet and just show what is within a box.

Ashley

edit: also, faulknermano explained it well and added another idea that would make it even more flexible: