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
Issue:
The pivot used in LDtk editor for autotiled sprites is not respected in the library, which is visible when used with sprites more than 1 tile big. The pivot used in the library is equal as if all pivot in rules-based tiles was set to the bottom-right corner.
Example:
scrnshot from the current unchanged platformer example, inside the LDtk editor:
The rule is always based on the center grid.
It is shown on the map with a violet frame. The pivot says that the picture of this gray shelf should be in the middle of that frame, but this pivot is not respected in the actual loaded game with the library:
The shelf is drawn one grid to the left from where it should be.
In this situation it is not a big issue in the case of platformer, where autotiles are used as random scatters, but this is a big issue when
a) it is either important to be precisely aligned with the surroundings
b) when the concerned intGrid has other effects, like collision. If this shelf had collision, the player would bump into the empty space next to the shelf.
Example from my own project where the auto tiles are drawing trees and stumps.
Not only are they visually not in the right alignment with the fences (the fences just one tile big, so this issue doesn't apply to them), but when used with collision, the player would collide with the grid (as desired) but the tree sprite is somewhere else.
I can workaround this by redoing the auto-tiles as objects, but this should be fixed if somebody can find the cause, or introduce the feature to the library. It would be impossible to properly use auto-tiles bigger than one tile.
I hope my explanation was clear.
Thanks to anybody working on this amazing library and anybody helping out!
The text was updated successfully, but these errors were encountered:
Thanks again for another detailed report. This has been an issue since the beginning that originally would've been nasty to support. I think it might be much more reasonable to implement now thanks to bevy_ecs_tilemap's rewrite, but I'm not 100% sure.
LDtk: 1.2.4
bevy_ecs_ldtk: 0.5
bevy: 0.9
Issue:
The pivot used in LDtk editor for autotiled sprites is not respected in the library, which is visible when used with sprites more than 1 tile big. The pivot used in the library is equal as if all pivot in rules-based tiles was set to the bottom-right corner.
Example:
scrnshot from the current unchanged platformer example, inside the LDtk editor:
The rule is always based on the center grid.
It is shown on the map with a violet frame. The pivot says that the picture of this gray shelf should be in the middle of that frame, but this pivot is not respected in the actual loaded game with the library:
The shelf is drawn one grid to the left from where it should be.
In this situation it is not a big issue in the case of platformer, where autotiles are used as random scatters, but this is a big issue when
a) it is either important to be precisely aligned with the surroundings
b) when the concerned intGrid has other effects, like collision. If this shelf had collision, the player would bump into the empty space next to the shelf.
Example from my own project where the auto tiles are drawing trees and stumps.
Not only are they visually not in the right alignment with the fences (the fences just one tile big, so this issue doesn't apply to them), but when used with collision, the player would collide with the grid (as desired) but the tree sprite is somewhere else.
I can workaround this by redoing the auto-tiles as objects, but this should be fixed if somebody can find the cause, or introduce the feature to the library. It would be impossible to properly use auto-tiles bigger than one tile.
I hope my explanation was clear.
Thanks to anybody working on this amazing library and anybody helping out!
The text was updated successfully, but these errors were encountered: