Skip to content
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

Improvement to tilemap editor with 3x3 autotile bitmask #31003

Open
paulmasri opened this issue Jul 31, 2019 · 5 comments
Open

Improvement to tilemap editor with 3x3 autotile bitmask #31003

paulmasri opened this issue Jul 31, 2019 · 5 comments

Comments

@paulmasri
Copy link

Godot version: 3.1.1

OS/device including version: MacOS 10.14.4

Issue description:
When painting in the Tilemap editor in 3x3 autotile bitmask mode, corners are missing when diagonals are drawn.

The 3x3 bitmask has 9 bits per mask. This leads many to believe there are 2^9 = 512 bitmask combinations. However the tilemap editor only draws tiles where the centre bit is set (2^8 = 256 combinations).

In most situations this is perfect, and means that tileset designers have a lot less tiles to design. However it results in those missing corners at the outer diagonal edges.

Example showing missing corners:

Screenshot 2019-07-31 at 21 43 31

Same example showing the tile bitmasks:

Screenshot 2019-07-31 at 21 44 17

Suggestion:

Add support to the tilemap editor for the following bitmask combinations and render these onto tile squares that have not been painted but which have 2, 3 or 4 painted tiles connected to them vertically and horizontally.

Godot tileset edges

This would have the following effect on the example above:

Same example with corner tiles:

Screenshot 2019-07-31 at 22 07 35

Same example showing tile bitmasks including the new corner tiles:

Screenshot 2019-07-31 at 22 12 36

Contributing:

I'm a C++ coder and I would be happy to contribute. However I am totally unfamiliar with this codebase and, having looked at the relevant class, I wouldn't know where to start. If you would like me to have a go at writing in this functionality, would you be willing to explain which parts of it are relevant and give me hints as to what I'd need to do?

Alternatively, if you're able to do it, I'd love to see this in 3.1.2. 😁

@SpechtMagnus
Copy link
Contributor

There is one big problem I see with this proposal. A zero in a tile's bitmap doesn't necesserily mean that there is no tile at all but rather that there is no tile of the same texture. Additionally the bitmask only decides which tile of a texture map to put into the specific tile. If the tile is colored with another texture this check will never happen.
So I fear this feature is just not possible/practical with the current implementation.

@2rsvold
Copy link

2rsvold commented Feb 10, 2020

I have had a look into the same problem. After using bitmask for a while, and loving it, I tried to look into what the bitmask actually does to better understand it rather then just following what the different tutorials said.

So after obtaining the knowledge of how they actually worked, I was surprised to discover that this kind of "corner case" wasn't supported.

Take this bitmask, that I tried to use to create a border around my art:
pixil-frame

With my understanding of the bitmask, you would think that this would paint this tile if there are tiles to the right, top-right and bottom-right of the current "unpainted"-tile, but sadly this is not the case.

To answer to @SpechtMagnus's comment, I do belive this would be possible. Yes, if the tile is already painted, this would have no effect. But, as in my case, you could use this feature by having your tiles on there own tilemap. To be more presise: I have a "wall tilemap" on its own tilemap that has "trimming" in the texture, and the floor is it's own tilemap rendered below the "walls". In this case the "not painted center, but sides"-bitmask would occur, and would be really nice to have for my level designers who only uses this tool, and don't really know how to set it up.

I was also thinking of adding this to the autotile "placement", but got a bit lost in the code, just like @KoBeWi, event though I have a "solution in my head".

@golddotasksquestions
Copy link

I desperately need this. Setting single tiles on top for now is a painful workaround, and makes procedural Tilemap generation really complicated. I try to postpone Tilemap work as much as possible, but I will have to do it eventually.

@golddotasksquestions
Copy link

golddotasksquestions commented May 16, 2020

Is this still an issue with the new wildcard feature?
Unfortunately I don't have a 3x3 (not minimal) reference tileset, and I'm also not a 100% sure how I would have to test this issue with wildcards, otherwise I already would.

@SpechtMagnus
Copy link
Contributor

Yes, this issue is completely independent of the wildcard feature I implemented. The wildcard feature only allows to reduce the number of tiles needed for a complete tilemap.

As I described above the code that determines witch tile to use only runs when the respective tile is painted with a texture that contains autotile information. Letting this code also run for unpainted cells would mean that the editor would have to check the entire tileset for every empty cell and every autotile that could be drawn at this location. This causes two huge problems:

  1. What tile should the editor draw when multiple autotile textures would be valid
  2. and most important this would cause a huge performance impact especially for tilesets with many autotile textures.

So once again I don't think this is feasible. You could instead redraw your tiles so that all the corners are inside of the tiles. This would be way easier and works with the current implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants