Looks like it does all 3 of those events because the condition is met for all 3 to be run.

maybe try:

Game pad a is pressed,

if text a

-destroy text a, set text b visible

else if text b

-destroy text b, set text c visible

else if text c

-destroy text c, go to level 1

You would put the if and elses into subevents inside the gamepad event.

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.

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!

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.

>

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

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.

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"?

>

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

As far as I understand, the more the renderer has to change tiles when it renders them, the slower it goes. So if you have a big space of the same tile, it will render quicker than a space consisting of different tiles.

Also, if you stack and overlap tilemaps, that also adds to the rendering process, therefor slowing it down.

This is what I have experienced.

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.