Skip to content
This repository has been archived by the owner on May 7, 2022. It is now read-only.

Issues while using this library for the first time #163

Open
ChristianIvicevic opened this issue Jun 3, 2021 · 1 comment
Open

Issues while using this library for the first time #163

ChristianIvicevic opened this issue Jun 3, 2021 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@ChristianIvicevic
Copy link

ChristianIvicevic commented Jun 3, 2021

Currently I am evaluating bevy and the 3rd party plugins and have been toying around with bevy_tilemap as well. Unfortunately I had many issues to get up and running in the first place that I wanted to leave a feedback to make you aware of them:

  1. The section "Simple tilemap construction" is misleading as the code in there is outdated and the set_tile method no longer existing. Only by studying the square tile example I was able to deduce how to generate a tilemap myself.
  2. Speaking of that example, both your example and the one from the original bevy repository are needlessly complex when building a texture atlas. I do understand it's possible and nice to dynamically build an atlas of existing textures, but this is introducing serious cognitive overhead - especially with bevy being barely documented to begin with. I would've appreciated working with a single texture in the example that contains 2-3 different tiles already just to be able to focus on using bevy_tilemap itself rather than distinguishing bevy features and patterns itself.
  3. Generating new Tiles and adding them with Tilemap::insert_tiles caused me some headaches since the point member is apparently in tile units (and the dimensions of the tilemap in chunks rather than tiles). Units of measurement are pure guesswork and not documented properly.
  4. Even more confusing is that I haven't found any indication about the tilemap grid orientation whatsoever. You can imagine me being surprised that the map I have defined was suddenly growing towards the top-left (due to the grid using a classic cartesian coordinate-system with the origin being in the bottom-left rather than top-left for example) making it slightly more annoying to build a tilemap that is naturally built and flowing towards the bottom-right. Therefore when reading a map from a file I have to build the tilemap in a non-natural way and logical tile coordinates (like 2nd row, 3rd column) don't map nicely to their actual position in the tilemap since it may be something like (31, 3).
@ChristianIvicevic ChristianIvicevic added the bug Something isn't working label Jun 3, 2021
@joshuajbouw
Copy link
Owner

Thanks for the heads up. I'll start tracking these once I have made the time.

joshuajbouw pushed a commit that referenced this issue Jun 21, 2021
Following the request 1 in #163, I updated the example to use simpler defaults and the current API.

Changes include:
- Using the default Tilemap to avoid calling `spawn_chunk_at_point` later.
- Explained the use of `HandleId::random::<TextureAtlas>`
- Put the tilemap up top and texture atlas work a little lower.
- Expanded out Tile and explained all the data
- Used `insert_tile` rather than `set_tile`
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants