-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"overflow" layer_entities too large #227
Comments
I spent some more time on this issue. I made a small level in LDTK to reproduce it, and it got messy quick. Default options in LDTK prevent the issue from happening in a lot of cases and #228 is broken in a few ways, mostly in how I set coordinates. In working through the issues, though, I've come to believe that creating invisible tiles for Auto-layer layers doesn't serve a purpose in the most common use of LDTK. I realize this opinion does have a decent amount of ignorance behind it (I'm not the one who's been working on this library for years), but I've submitted a PR for consideration anyway. Feel free to disregard. |
To elaborate on the purpose of invisible tiles in general - it's pretty much exclusively to ensure that intgrid cells will spawn appropriately for intgrid+autotile layers. Intgrid values tend to be pretty important to game logic and the APIs provided by this plugin. So, on intgrid+autotile layers, tiles with a nonzero intgrid value need to exist whether or not the autotile rules of that layer determine that they have a tileset value. Conversely, the tile needs to exist (and be visible) on intgrid+autotile layers if it has a tileset value but happens to have a 0 intgrid value. That being said, the issue of the overflow layers also containing these tiles is a definitely a bug. Only the bottom sub-layer should be concerned with int grid logic, so spawning invisible tiles for them on the remaining sub-layers is wrong and it was a good catch. Haven't checked out your PR yet btw - just giving some extra context here |
Thank you for the context, that makes a lot of sense. Based off that, I've tweaked my approach and opened up a new PR here: #231 |
Implemented in #231 |
Expected Result
Given a 10x10 int_grid named "map" with 10 tiles in one space and one tile in the remaining spaces,
spawn_level
should spawn 1 entity named "map" with 100 tiles, and 9 additional "map" entities each with 1 tile each to cover the "overflow"Observed Result
Given the same map as above,
spawn_level
will spawn 1 "map" entity with the correct 100 tiles, and then the 9 overflow map entities will also have 100 tiles each, 99 of which are invisible tiles. All the invisible tiles can take a big toll on performance and memory in larger levels.Suspected cause
layer_grid_tiles
splits the tiles into correctgrid_tiles
Vecs,tile_pos_to_tile_if_int_grid_nonzero_maker
checks against the wholeint_grid_csv
array on where to create a tile, and notgrid_tiles
, so an invisible tile is created where ever a tile exists on anylayer_entity
I've made a fix for this issue in my fork, and I've included a PR for it here: #228
The text was updated successfully, but these errors were encountered: