You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A 2D platformer with player character using an AnimatedSprite2D.
Describe the problem or limitation you are having in your project
I noticed that my run cycle, defined as SpriteFrames for my AnimatedSprite2D, was odd. After comparing the end result to the original spritesheet, I noticed that my character sprites was not ordered the same way as expected. Selecting the frames again in the correct order, I realized that the order in which you select frames is important, and is used for the final animation.
While this is understandable, as the editor cannot guess how the sprites are supposed to be ordered, there is no feedback on the selection order, nor indication that the selection order will be used, making users potentially think that the frames will be spatially ordered, and end up with the wrong sprite order.
In addition, in most cases, spritesheet already order the frames horizontally or vertically, so it would be nice to be able to auto-enforce such ordering.
When using shift-select to batch select frames, they seem to be selecting in horizontal order, top-to-bottom, but when clicking on a sprite more in the top-left direction next, the frames will be selected bottom-to-top.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
For the feedback part:
We could indicate the index of every selected frame with a small number in the corner of the selected box (semi-transparent or with an option checkbox to hide, if it prevents the user from seeing the sprites correctly).
For horizontal/vertical ordering:
We could add a dropdown to select ordering mode:
a. Selection order (current behavior)
b. Horizontal, top to bottom (the most common one)
c. Horizontal, bottom to top (to be exhaustive)
d. Vertical, left to right (the second most common one, I suppose)
e. Vertical, right to left (to be exhaustive)
If we also do the number feedback suggestion above, the numbers would immediately update to match the select ordering mode.
This should be compatible with shift-click for batch selection too.
While this makes 2 suggestions and could be submitted as 2 PR, I feel that those two features mix well together, as the number indication will help the user understand how ordering modes differ, so I put them in the same suggestion.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Frame numbers:
(in the picture it starts at 1, but it could also start at 0 to match the actual index offset; and of course, it becomes useful when it's not ordered spatially)
Ordering mode dropdown:
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, it's probably too close to native editor windows to do so.
Is there a reason why this should be core and not an add-on in the asset library?
No, it's probably too close to native editor windows to do so.
The text was updated successfully, but these errors were encountered:
Selecting the frames again in the correct order, I realized that the order in which you select frames is important, and is used for the final animation.
Actually, currently adding frames to the animation in the selection order is not guaranteed. The frames selected in that dialog are stored in a hash set and they're added to the animation according to the iteration order over such set of selected frames. So ordering is currently pretty much undefined, the fact it ends up being the selection order is by luck, it's a result of an implementation detail. It's unreliable and it can definitely be treated as a bug (at least from the usability point of view).
Regarding the proposal, maybe a Frame order dropdown with options:
Selection order,
Vertical then horizontal,
Horizontal then vertical.
And if 2. or 3. is selected then two additional dropdowns:
Vertical order:
Top to bottom,
Bottom to top.
Horizontal order:
Left to right,
Right to left.
?
Or maybe just a single dropdown (would take less space) with 1 + 8 = 9 options (selection order + all possible top/bottom and left/right combinations listed directly)?
Describe the project you are working on
A 2D platformer with player character using an AnimatedSprite2D.
Describe the problem or limitation you are having in your project
I noticed that my run cycle, defined as SpriteFrames for my AnimatedSprite2D, was odd. After comparing the end result to the original spritesheet, I noticed that my character sprites was not ordered the same way as expected. Selecting the frames again in the correct order, I realized that the order in which you select frames is important, and is used for the final animation.
While this is understandable, as the editor cannot guess how the sprites are supposed to be ordered, there is no feedback on the selection order, nor indication that the selection order will be used, making users potentially think that the frames will be spatially ordered, and end up with the wrong sprite order.
In addition, in most cases, spritesheet already order the frames horizontally or vertically, so it would be nice to be able to auto-enforce such ordering.
When using shift-select to batch select frames, they seem to be selecting in horizontal order, top-to-bottom, but when clicking on a sprite more in the top-left direction next, the frames will be selected bottom-to-top.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
For the feedback part:
We could indicate the index of every selected frame with a small number in the corner of the selected box (semi-transparent or with an option checkbox to hide, if it prevents the user from seeing the sprites correctly).
For horizontal/vertical ordering:
We could add a dropdown to select ordering mode:
a. Selection order (current behavior)
b. Horizontal, top to bottom (the most common one)
c. Horizontal, bottom to top (to be exhaustive)
d. Vertical, left to right (the second most common one, I suppose)
e. Vertical, right to left (to be exhaustive)
If we also do the number feedback suggestion above, the numbers would immediately update to match the select ordering mode.
This should be compatible with shift-click for batch selection too.
While this makes 2 suggestions and could be submitted as 2 PR, I feel that those two features mix well together, as the number indication will help the user understand how ordering modes differ, so I put them in the same suggestion.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Frame numbers:
(in the picture it starts at 1, but it could also start at 0 to match the actual index offset; and of course, it becomes useful when it's not ordered spatially)
Ordering mode dropdown:
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, it's probably too close to native editor windows to do so.
Is there a reason why this should be core and not an add-on in the asset library?
No, it's probably too close to native editor windows to do so.
The text was updated successfully, but these errors were encountered: