Allow resizing, but via adding/removing rows/columns

[foxnne]

I've been considering allowing file resize, but with respect to animations and sprite names, this could get messy quickly.

As .pixi files are typically much larger than they have to be, and new files can be created easily to allow more sprites to the final packed atlas, I think the best way to allow "resizing" of the whole artboard is to go with an approach that allows you to add/remove rows and columns. This would need to create a new image per layer and copy/edit the artwork to the new image without destroying all previously created animations.

[alterae]

Massively in-favor of this. The whole atlas-oriented design is extremely appealing to me, but the inability to resize files (combined with my own inability to predict how large a file I'll need) is a bit of a blocker.

[foxnne]

@alterae Thank you for your input! In the meantime, generally I just create a new file anytime I need more space, as all of the files will be packed together. But I totally agree that I need to make files resizable. I just need to commit some time to figuring out how to tie something like that into the undo/redo system and also how to handle changing existing animations when the document layout changes.

Feel free to share your input if you've got some ideas!

[alterae]

i think the "intuitive" (and almost certainly naïve) way for me is like, given a starting grid as follows:

if the grid resizes and no occupied cells are affected, things just stay as they are:

if the grid resizes and occupied cells are affected, but there's still space for them, they wrap around like so:

and if the grid resizes like that but there isn't space for all the cells, cells at the end get removed and any animations that go past the end get truncated, as shown here:

things of note:

• this assumes that the grid is sorta treated like a linear array of cells, with length $l = w * h$.
• i'm defining an "occupied" cell as any cell that has any pixels drawn in it or any metadata added by the user. basically any cell not in its default state
  • unoccupied cells before the last occupied cell are treated as occupied cells for the purposes of resizing
• i'm only really familiar with the normal frame-by-frame animations. i haven't used keyframe animations and don't know how those would work with this. maybe similarly?
  • i'm assuming animations can wrap around row breaks. i have no idea if this is actually the case.

i have absolutely no idea how feasible this is to implement (nor how closely it lines up with the editor's actual data structures (i have no idea how the data is structured internally)) but if the end behavior were something like this i think it would be relatively low-surprise

as for undo/redo, i have even less useful input on the implementation, but i will say that any cells or animations that are lost in a resize should be stored so they can be re-added on undo, and any animations that are truncated should have their previous size/bounds stored somehow for the same reason

i hope at least some of this is helpful

[foxnne]

This is great, thank you so much for the effort (and pretty drawings) you've included here, I think this is a great way to implement it and I will be starting on this soon. :)

I think that with the current way the data is structured, where individual sprites are just coordinates to a location of the full file image size, letting you drag a crop window isn't the best option, but instead maybe something like inserting/appending rows/columns via something intuitive on the canvas. I'll think about the best way to build this into the UI.

Thanks again for your input!