C3 Spritesheet feature isn't true spritesheeting :(

Post » Sat Mar 18, 2017 10:13 pm

faulknermano wrote:What @prominent is trying to explain is how to use a single image as a basis from which C3 is to derive multiple frames. To work with a single spritesheet (image) is the very point. Placing it in the animation (film strip) window nullifies the main idea because the film strip shows discrete frames, and whole point is to have a full spritesheet to work from.

In my view, in this system that prominent is suggesting, the film strip could be the means of viewing the animation frames as defined by the 'spritesheet editor'. But yes, the window to edit the spritesheet may look different (ie different spritesheet-centric functions) for the user to immediately see the context of the edit.

I think each Animation could have a property that controls which image and context its sourcing from: single frames, spritesheet. If single frames, then a list of image frames is populated, and we are working in the same way we do in C2.

If we use the spritesheet as a source, then that's a different data, where we are sourcing a 'spritesheet object', whereby a single image is used, and then bounding boxes defined which extract the pixel information, then generates a list of images based on the extraction.


Yes, exactly. Thanks for explaining it so well :)
And I really like your idea of having a property for each animation where you can choose the image/context!
B
47
S
22
G
65
Posts: 1,127
Reputation: 38,395

Post » Sat Mar 18, 2017 10:39 pm

Im curious about something. Presently I work using Aseprite which is great in my opinion for pixel art animations. But my problem is that I cannot use the json files which can be exported from it to use the tag system found in aseprite.

I think C3 would greatly facilitate the task of importing animations if it could import this json file with the animations.
Also, I found something like this to be useful or an interesting idea. The Ability to store info in animation frames.
https://2-hit-studio.itch.io/frame-boy
B
43
S
12
G
14
Posts: 488
Reputation: 10,570

Post » Sat Mar 18, 2017 11:42 pm

newt wrote:Im saying all such editing of animations should happen in an animations window.
I don't know how to say it any simpler than that.

You can do a lot of tweaking without the need for onion skinning and whatnot. I know when I need to adjust an animated sprite's palette I prefer to spend a few minutes editing a handful of sprite sheets rather than hours re-importing all the frames one by one.
B
39
S
16
G
6
Posts: 543
Reputation: 7,619

Post » Sun Mar 19, 2017 1:34 am

ErekT wrote:
newt wrote:Im saying all such editing of animations should happen in an animations window.
I don't know how to say it any simpler than that.

You can do a lot of tweaking without the need for onion skinning and whatnot. I know when I need to adjust an animated sprite's palette I prefer to spend a few minutes editing a handful of sprite sheets rather than hours re-importing all the frames one by one.


Im not saying you can't have the option to do some functions in the animation editor. Editing a palette is a realistic expectation (it deserves specific tools to do so), having access to the whole spritesheet to do brush work is not.
Image ImageImage
B
170
S
50
G
179
Posts: 8,379
Reputation: 113,427

Post » Sun Mar 19, 2017 10:22 am

You should try using flash and photoshop to create your png seq.
Make your fixes there, and then you can easily export a png sqe from flash and place it in 2
B
41
S
16
G
7
Posts: 55
Reputation: 6,498

Post » Sun Mar 19, 2017 12:57 pm

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?
Scirra Founder
B
399
S
236
G
89
Posts: 24,521
Reputation: 195,375

Post » Sun Mar 19, 2017 5:42 pm

Ashley wrote: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.
Ashley wrote: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.

Ashley wrote: 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.

Ashley wrote: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.
B
47
S
22
G
65
Posts: 1,127
Reputation: 38,395

Post » Tue Mar 21, 2017 7:09 pm

Ashley wrote: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.
B
84
S
46
G
25
Posts: 529
Reputation: 21,568

Post » Sat Apr 01, 2017 6:33 am

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.
Last edited by LeoSantos on Sat Apr 01, 2017 9:48 am, edited 1 time in total.
B
6
S
3
G
2
Posts: 9
Reputation: 1,548

Post » Sat Apr 01, 2017 8:38 am

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.
B
48
S
10
G
9
Posts: 1,224
Reputation: 8,449

PreviousNext

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 2 guests