-
Notifications
You must be signed in to change notification settings - Fork 199
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
Choice of hex tile size in examples prevents pixel-perfect tiling #456
Comments
An important information to be considered in this context is that bevy automatically calculates a scale factor for each window, which may be something like 1.08333 if you have exotically sized screens. You can override that thing:
Furthermore, you probably want to turn off anti-aliasing:
I'm preparing a patch that gets rid of the sqrt(3) calculations and rather calculates the tile offsets from the given grid size using divisions by 2 and 4. That way a nicer grid size (like 28x32, for example) actually has an effect. If you do the sqrt(3) calculations, the calculation errors add up and your pixels will still be "off" in some places. |
By refraining from using sqrt(3) based arithmetics we get the tiles aligned to the provided textures and grid size. This is not mathematically exact, but arguably what the user wants when providing tiles of specific size. The central realization here is that neighboring tiles on the "diagonal" axis are always offset by a half tile size in one direction and a 3/4 tile size in the other. So, by providing tiles with sizes divisible by 4, you can get pixel perfect alignment of tiles. The calculations are also quite a bit simpler this way. See StarArawn#456 for some further comments on this.
By refraining from using sqrt(3) based arithmetics we get the tiles aligned to the provided textures and grid size. This is not mathematically exact, but arguably what the user wants when providing tiles of specific size. The central realization here is that neighboring tiles on the "diagonal" axis are always offset by a half tile size in one direction and a 3/4 tile size in the other. So, by providing tiles with sizes divisible by 4, you can get pixel perfect alignment of tiles. The calculations are also quite a bit simpler this way. See StarArawn#456 for some further comments on this.
By refraining from using sqrt(3) based arithmetics we get the tiles aligned to the provided textures and grid size. This is not mathematically exact, but arguably what the user wants when providing tiles of specific size. The central realization here is that neighboring tiles on the "diagonal" axis are always offset by a half tile size in one direction and a 3/4 tile size in the other. So, by providing tiles with sizes divisible by 4, you can get pixel perfect alignment of tiles. The calculations are also quite a bit simpler this way. See StarArawn#456 for some further comments on this.
By refraining from using sqrt(3) based arithmetics we get the tiles aligned to the provided textures and grid size. This is not mathematically exact, but arguably what the user wants when providing tiles of specific size. The central realization here is that neighboring tiles on the "diagonal" axis are always offset by a half tile size in one direction and a 3/4 tile size in the other. So, by providing tiles with sizes divisible by 4, you can get pixel perfect alignment of tiles. The calculations are also quite a bit simpler this way. See StarArawn#456 for some further comments on this.
By refraining from using sqrt(3) based arithmetics we get the tiles aligned to the provided textures and grid size. This is not mathematically exact, but arguably what the user wants when providing tiles of specific size. The central realization here is that neighboring tiles on the "diagonal" axis are always offset by a half tile size in one direction and a 3/4 tile size in the other. So, by providing tiles with sizes divisible by 4, you can get pixel perfect alignment of tiles. The calculations are also quite a bit simpler this way. See StarArawn#456 for some further comments on this.
By refraining from using sqrt(3) based arithmetics we get the tiles aligned to the provided textures and grid size. This is not mathematically exact, but arguably what the user wants when providing tiles of specific size. The central realization here is that neighboring tiles on the "diagonal" axis are always offset by a half tile size in one direction and a 3/4 tile size in the other. So, by providing tiles with sizes divisible by 4, you can get pixel perfect alignment of tiles. The calculations are also quite a bit simpler this way. See StarArawn#456 for some further comments on this.
By refraining from using sqrt(3) based arithmetics we get the tiles aligned to the provided textures and grid size. This is not mathematically exact, but arguably what the user wants when providing tiles of specific size. The central realization here is that neighboring tiles on the "diagonal" axis are always offset by a half tile size in one direction and a 3/4 tile size in the other. So, by providing tiles with sizes divisible by 4, you can get pixel perfect alignment of tiles. The calculations are also quite a bit simpler this way. See StarArawn#456 for some further comments on this.
The hex tiles are 15x17 pixels. Since when hex-tiling the rows or columns are offset by half a tile and neither the width nor the height are integer-divisible by 2, you necessarily get a pattern where every other "column" or "row" looks somewhat off. It took me a while to figure out that this was not some rendering deficiency but simply a matter of choosing even numbers for the sizes.
The text was updated successfully, but these errors were encountered: