C3 Spritesheet feature isn't true spritesheeting :(

Why couldn't the animations window show all that rather than some dumb film icon?

Why couldn't the animations window show all that rather than some dumb film icon?

I don't understand what you mean. What are you referring to when you say "all that"? and what do you mean by "film icon"?

Show the strip in the animations window rather than the image editor.

The image editor is for editing images.

It would seem appropriate that the animations window would be for all elements of editing animations.

Show the strip in the animations window rather than the image editor.

The image editor is for editing images.

It would seem appropriate that the animations window would be for all elements of editing animations.

You'd still be able to edit the image in the image editor. So I don't understand your point, because you already use the image editor to place imagepoints and collision polygons- why not use the image editor to position where the frames correspond to as well. So the way I present it allows for the user interface to remain the same instead of changing things as you seem to be suggesting.

> Show the strip in the animations window rather than the image editor.

> The image editor is for editing images.

> It would seem appropriate that the animations window would be for all elements of editing animations.

>

You'd still be able to edit the image in the image editor. So I don't understand your point, because you already use the image editor to place imagepoints and collision polygons- why not use the image editor to position where the frames correspond to as well. So the way I present it allows for the user interface to remain the same instead of changing things as you seem to be suggesting.

It would be easier to redo an element that does very little rather than change one that does a lot already, to add something it's not designed to do.

Its designed to show one frame at a time.

Im saying anything that is to show multiple frames should be in a separate window.

>

> > Show the strip in the animations window rather than the image editor.

> > The image editor is for editing images.

> > It would seem appropriate that the animations window would be for all elements of editing animations.

> >

> You'd still be able to edit the image in the image editor. So I don't understand your point, because you already use the image editor to place imagepoints and collision polygons- why not use the image editor to position where the frames correspond to as well. So the way I present it allows for the user interface to remain the same instead of changing things as you seem to be suggesting.

>

It would be easier to redo an element that does very little rather than change one that does a lot already, to add something it's not designed to do.

Its designed to show one frame at a time.

Im saying anything that is to show multiple frames should be in a separate window.

It still would only show one image. I don't think you understand the implications. The benefit here is you work with ONE image. My suggestion requires less work than your sugestion. And this can be used in a new object type named Spritesheet, it doesn't have to be the Sprite object.

It would need to be this way so you can still paint across the entire spritesheet, edit it as a whole, etc.

If you're not open to suggestions that's fine, just don't expect it from others.

If you're not open to suggestions that's fine, just don't expect it from others.

I never asked for suggestions. You criticized my suggestions, so I'm criticizing yours because I feel your arguments don't carry much weight. All you have said has been very vague and aren't very constructive. So maybe you should invest more time in your posts and make clear what you mean when you criticize other people's work.

I've gone into detail about how I see a spritesheet feature implemented, even working within the design of Construct's existing UI; showing images to illustrate my points.

I've been in this business 20 years. I think I know a thing or two about this stuff.

So you can make your vague posts and pick at little things, but I'm trying to make a point here for the benefit of all users- don't get in the way of that please.

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.

Theres three windows, the image editor, the frames editor, and the animations editor.

I haven't criticized anything, I suggested placing all that was suggested into the animations editor, that we don't even need currently as it could be integrated into the image editor since all it does now is work as a simple list editor.

A sprite sheet requires the frames to be stitched together at some point. That either happens before it is imported, or after.

The odds of getting features to do that in the current image editor are extremely low.

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.

That's with 17 years of game development, 9 of which are with Construct.

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!

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

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 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.

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