C3 Spritesheet feature isn't true spritesheeting :(

Frankly I'm just confused now. The thread seemed to start as having concerns about how to import spritesheets. I think importing over the existing animation frames from a spritesheet is a useful idea. Beyond that, I'm still not clear what you want.

Those screenshots you showed look exactly like what the importer would do. You set the cell sizes and then the editor knows what individual frames are. Whether or not it displays the entire spritesheet in the editor doesn't seem particularly significant to me - why is it useful to see the rest of the frames when editing a collision poly, for example? What does that make possible that was difficult before? It seems fine to just edit that kind of thing frame-by-frame. That seems like a useful view to see when importing a spritesheet, but once the editor knows what the individual frames are... what's the benefit of still treating it like a whole spritesheet?

Also as I said before, if you force C3 to use an unmodified spritesheet, it effectively is a deoptimisation. You also can't do things like "crop all frames" which allows for a much tighter automatic spritesheet packing which saves memory, and also actually decreases the GPU fillrate which improves rendering performance. Your screenshots could probably save at least half the space, since there's a lot of transparency there. And with other images there could be issues with color bleed. So as far as I can tell, a better spritesheet importer would solve your problem and not have any significant downsides. Am I missing something?

Those screenshots you showed look exactly like what the importer would do. You set the cell sizes and then the editor knows what individual frames are.

How would it know which cells correspond to which frames?

If I have a spritesheet with 10 animations on it, and 5 of them share the same frame, or if any of the animations have frames that aren't organized in a linear fashion, how would the importer understand how to import that?

The method I proposed would cover that possibility. So, I'd like to know how your importer would handle that.

Whether or not it displays the entire spritesheet in the editor doesn't seem particularly significant to me - why is it useful to see the rest of the frames when editing a collision poly, for example?

Seeing the whole spritesheet allows more flexibility for editing the image, and making any potential changes to the organization of frames.

You haven't shown how your importer would solve the issue of correspondence. So with your method there is potential to have to rebuild the polygons.

How would your importer handle changes to frame correspondence? Say I have imported a spritesheet. Then I make changes externally that have modifications to the frame order, frame sharing, new frames inserted, frames subtracted, etc. If I reimport the spritesheet, how does your importer handle all of it without having to rebuild the polygons or imagepoints, frame speeds, animation loop/speed settings?

So far you haven't explained how it would solve these concerns.

What does that make possible that was difficult before? It seems fine to just edit that kind of thing frame-by-frame. That seems like a useful view to see when importing a spritesheet, but once the editor knows what the individual frames are... what's the benefit of still treating it like a whole spritesheet?

It allows the user to edit ONE image without having to click through a bunch of panels to edit a whole animation. It essentially smooths the workflow so the user can focus on working on the graphics. If I want to make some pixel modifcations on all the frames, I can do it quicker if I don't have to click through all the animations and frames, changing tools constantly in the process.

It also allows the possibility of adding a contiguous option to the floodfill tool that can make adjusting colors across all frames with one click.

Basically any edits you can make to one frame now becomes easier because you are editing just one image.

Also as I said before, if you force C3 to use an unmodified spritesheet, it effectively is a deoptimisation. You also can't do things like "crop all frames" which allows for a much tighter automatic spritesheet packing which saves memory, and also actually decreases the GPU fillrate which improves rendering performance. Your screenshots could probably save at least half the space, since there's a lot of transparency there. And with other images there could be issues with color bleed. So as far as I can tell, a better spritesheet importer would solve your problem and not have any significant downsides. Am I missing something?

You could still optimize the spritesheets on export. Maybe some people might not want them optimized, so maybe it could be optional.

You seem to imply that the methods I proposed would prevent you to optimize the spritesheets further, but that is a lie. You can cut the spritesheet up into individual frames and reoptimize them when exporting the project if you wanted to. The purpose of having workable spritesheets in the editor is to make editing graphics/sprites a lot easier- to make the workflow smoother.

Everyone who wanted spritesheets, wanted a workable form inside the editor to solve the workflow issues, and they expected it to be in c3 because you said it would be in it. If you don't want to implement it, just say so and I won't waste my time anymore.

Frankly I'm just confused now. The thread seemed to start as having concerns about how to import spritesheets. I think importing over the existing animation frames from a spritesheet is a useful idea. Beyond that, I'm still not clear what you want.

Those screenshots you showed look exactly like what the importer would do. You set the cell sizes and then the editor knows what individual frames are. Whether or not it displays the entire spritesheet in the editor doesn't seem particularly significant to me - why is it useful to see the rest of the frames when editing a collision poly, for example? What does that make possible that was difficult before? It seems fine to just edit that kind of thing frame-by-frame. That seems like a useful view to see when importing a spritesheet, but once the editor knows what the individual frames are... what's the benefit of still treating it like a whole spritesheet?

Also as I said before, if you force C3 to use an unmodified spritesheet, it effectively is a deoptimisation. You also can't do things like "crop all frames" which allows for a much tighter automatic spritesheet packing which saves memory, and also actually decreases the GPU fillrate which improves rendering performance. Your screenshots could probably save at least half the space, since there's a lot of transparency there. And with other images there could be issues with color bleed. So as far as I can tell, a better spritesheet importer would solve your problem and not have any significant downsides. Am I missing something?

The issue may be the optimization being forced when the user may already have constructed an optimized spritesheet. There's also the question of whether such optimizations are really need in a desktop environment where saving a few MB isn't all that big of a deal. Being able to easily update a spritesheet and having C2/C3 import it without wiping out collision shapes, or being able to turn off what are occasionally problematic optimizations that end up causing seams in sprites, would be a big step forward in the way Construct handles spritesheets. It's also possible to manually process images through sometime like PNGGauntlet to provide more optimization (of file size on disk) that Construct provides, and currently this optimization is lost when importing into C2. This optimization can be re-applied after export, but this can be time-consuming when a lot of images are in use, and it has to be done every time.

In terms of seeing the entire spritesheet in-editor, this could be useful for users to ensure that they're using the most updated spritesheet visually, instead of having to, for example, go through every frame of an animation to make sure they're all up to date. It's a quality of life feature.

Hi, this is my first post in... years. The lack of better sprite support in C2 was one of the roadblocks that made me stop using it, despite liking everything else (the lack of a scene graph with true hierarchies, essential for complex projects, was the other factor... but that's off topic).

To me, the main problems with sprites in Construct are:

• Reimporting updated sprites is really essential, not just a bonus feature. A way to re-import the frames without losing all the work put into colliders, animations, etc, would be great.

• Defining the animations by loading all frames, then deleting the ones you don't want is super cumbersome from a UI design perspective. What if you delete unused frames for the first animation, then create a second? Import it all again and delete the ones you don't want again? What if you have a sprite with dozens of actions? You should be able to import the frames only once.

Bottom line is, you should be able to decouple a sprite from its bitmaps (animations, in this case, would be essentially lists of frame numbers plus attributes like loop, frame rate, etc.) , and simply load any spritesheet you want "into" a sprite.

Cheers.

Decoupling a sprite from its frames is very useful. It makes the program a bit less beginner friendly unfortunately, which I don't think Ashley wants. The way it could work in Construct is that when you add a new sprite object, instead of being taken directly into the image editor to define the first frame, a popup box appears and you can assign an animation(s) from the project resources bar/some new UI window containing animations. This would mean animations are globally accessible to the project and not tied to sprites; sprites simply inherit them. This would require a change to the UI of course. Being able to decouple frame data from the image as suggested here would also be nice; you would be able to reuse frames when defining animations. I doubt these things will be added however as they require big changes to the way construct works. A workaround which might be possible and would be very useful is a runtime action on sprites to inherit animations from another sprite type and add it to its own animation list. It would come in handy for certain in-game UI cases where the same animations/images need to be displayed on different object types. (think of a level editor, where every graphic in the game needs to be accessible to a single sprite type, or a fighting game character selection screen that displays the character). Sprite types should inherit animations, and animations should be able to share and reuse segments of spritesheets. Construct's current way of setting up animations frame by frame is good for beginners though, if they don't work with sprite sheets.

The lack of better sprite support in C2 was one of the roadblocks that made me stop using it, despite liking everything else (the lack of a scene graph with true hierarchies, essential for complex projects, was the other factor... but that's off topic).

To me, the main problems with sprites in Construct are:

- Reimporting updated sprites is really essential, not just a bonus feature. A way to re-import the frames without losing all the work put into colliders, animations, etc, would be great.

- Defining the animations by loading all frames, then deleting the ones you don't want is super cumbersome from a UI design perspective. What if you delete unused frames for the first animation, then create a second? Import it all again and delete the ones you don't want again? What if you have a sprite with dozens of actions? You should be able to import the frames only once.

Bottom line is, you should be able to decouple a sprite from its bitmaps (animations, in this case, would be essentially lists of frame numbers plus attributes like loop, frame rate, etc.) , and simply load any spritesheet you want "into" a sprite.

Cheers.

This would mean animations are globally accessible to the project and not tied to sprites; sprites simply inherit them.

...

A workaround which might be possible and would be very useful is a runtime action on sprites to inherit animations from another sprite type and add it to its own animation list.

These issues reflect my own concerns. I wrote an external 'C2 sprite manager' to mass apply settings onto the caproj in an effort to bypass the UI limitation of not being able to change settings on multiple selections/animation.

More recently I'm developing a workflow by using (and modifying) Rex's AnimationLoader plugin in order to dynamically load sprites and collision data at runtime. I might actually fuse those two functionalities together in the near future.

The hack/trick I've been using for these two workflows is the use of a simple text files alongside the images to define animation data, and in the latter case, collision data, which is created in Photoshop by using paths, and written out by a .jsx which I wrote, too.

The only snag here is that the frame length per animation must be pre-defined as it cannot grow/contract during runtime.

[quote:3q9qiqmq]

Decoupling a sprite from its frames is very useful. It makes the program a bit less beginner friendly unfortunately, which I don't think Ashley wants.

Perhaps. What do I know of making user-friendly software? For over 5 years, I wrote this plugin once for LW to manage render passes, but the best I could do was get LW users scratching their heads.

However, I do believe that if the guts of the application is flexible and open enough, the gui/skin/front-end can be simple enough for anyone, yet accessible enough for anyone who wants to get deeper. This is also why I feel rather disappointed at the lack (of news) of an Editor SDK in C3. It would have made all the difference for me, and given the kind of 3rd-party development I see going on around here, it would have made a lot of difference to all users. Perhaps it may still be around the corner. Who knows?