How to review spritesheets?

How to review spritesheets covered in this article, I can't find it anywhere?

https://www.scirra.com/blog/198/constru ... chitecture

Ashley And also is there any way to turn off this feature, or change how the editor bundles the sprites? I don't like my sprites scrambled up in random spritesheets to save a little bit of memory, because sometimes I edit exported sprites. (Color correction etc, for all character animation frames at once, level assets etc) Memory is usually not an issue these days, so I would rather have more control, or chose to optimize to use biggest possible sprite sheet, not smallest, and only bundle together sprites I chose to be bundled. I don't mind having a bit of transparent area space if it would mean fewer sprite sheets. Maybe an option on assets to be excluded from these scrambled spritesheets?

Wishing for.

1. Option to Select sprites that I want to exclude from the automatic spritesheeting bundling.

2. Option to change optimization algorithm (ie. Less memory usage, vs fewer spritheets)

Right click the project item in the project bar and select tools -> view spritesheets.

I am really against any micro-management features like tweaking how spritesheets work. It is time consuming when we have stacks of other far more interesting and useful things to be working on, creates difficult bugs which only happens with certain combinations of settings, is confusing to new users, and users who don't have an intimate understanding of the engine can easily actually make things worse for themselves by naively choosing the worst option. We already see this a lot with the "downscaling quality" option, where people choose "high" for no reason, which adds probably 50% to the memory usage of the game for no benefit. It's really hard to explain to people how to use these options correctly.

I am really against any micro-management features like tweaking how spritesheets work. It is time consuming when we have stacks of other far more interesting and useful things to be working on, creates difficult bugs which only happens with certain combinations of settings, is confusing to new users, and users who don't have an intimate understanding of the engine can easily actually make things worse for themselves by naively choosing the worst option. We already see this a lot with the "downscaling quality" option, where people choose "high" for no reason, which adds probably 50% to the memory usage of the game for no benefit. It's really hard to explain to people how to use these options correctly.

You're really hamstringing your software with this mindset. Quite a few artists have been asking/begging for this in the past. I've been asking for it since 2013. It really is a big deal if you have an animation-heavy game.

Still, you dismiss it on some wishy washy usability principle?? This is usability right here. Tuck it away out of reach for beginners if you think their minds are so feeble they can't deal with its presence. Jeez...

This thread is basically asking for a de-optimisation. There are far more users who want the engine to work optimally. And I am sure one of the reasons Construct is a success because it makes it harder to do things wrong.

tunepunk This was my suggestion which i think would work for your needs too and it was unfortunately declined: https://construct3.ideas.aha.io/ideas/C3-I-104

— there are far more users that don't care about this feature, sure. But wouldn't the fewer advanced users that are creating higher quality games (at least in the gfx area) give Construct more publicity and attract more developers?

Also the feature I submitted isn't confusing. Tag sprites to be packed together. If no tag then do the auto sprite sheet thing. Game development isn't easy. People will always be confused about something, then come to the forums to learn.

There are many users who specifically, actively do want the engine to be optimal. I also have not seen any evidence any of these features are actually necessary; if you did something like produce numbers showing high memory use due to spritesheeting or something like that, it would significantly strengthen your case. As it is it seems to be working fine so I don't want to do a lot of complicated technical work just because someone has a hunch.

Even if there was a problem with grouping, I would certainly want to try to solve it automatically first. A manual tagging system is boring to do and error-prone (you could easily actually make it worse by getting tags wrong), and the editor has a lot of information it could use to apply grouping automatically, such as inspecting which layouts objects are used together on. An automatic approach is certainly the first port of call, it's not a good idea to jump right away to tricky manual configuration.

There are many users who specifically, actively do want the engine to be optimal. I also have not seen any evidence any of these features are actually necessary; if you did something like produce numbers showing high memory use due to spritesheeting or something like that, it would significantly strengthen your case.

I'm not after performance. I want to be able to edit whole batches of sprite animations by accessing sprite sheets/texture atlases directly in the editor. As it is, I have to spend hours replacing sprite frames one by one if I want to change tweak some colors or anything else. With in-editor access to sprite sheets I could do that stuff in minutes.

That could, and probably should, be done via new Animation Editor import features instead. Editing spritesheets is impossible if the images get larger, for example.

Is it just me or does it seem like Scirra is a proponent of not optimizing a lot of stuff requested by users, stating it won't make much difference, and then also uses the counter argument in other cases, stating that they can't do it because it would be less optimized (and they conveniently don't provide numbers in this case).

am I crazy?

It's a catch 22 sort of thing.

The problem with animations is that you can't possibly know all you need before you start to set things up, and the system does not work well with constant revisions.

Then the system uses two modes, one for preview, and one for export. Its overly complicated to change things for either side of the argument.

Loadable animations would solve most things, except memory management, which I believe is a canvas issue.

My main point is this could well be a deoptimisation unless you have evidence it would actually help.

My main reason was mainly due to that I sometimes edit sprites after export. If they are all scrambed up in a random spritesheet it's hard for me to do any final touches. (Color corection, contrast fixes, effects etc in photoshop etc etc) I mainly do this after export on bigger spritesheets because it easier than to do it on evey single .png frame, and reimporting them to C2/C3 all over again.

That could, and probably should, be done via new Animation Editor import features instead. Editing spritesheets is impossible if the images get larger, for example.

Yeah, it would be limited to cases where the frames don't change sizes. Did you have anything specific in mind on how to solve it with the new animation editor?