Closed vkovtun closed 6 years ago
The problem is that all layouts use the same abstraction, hence the top-left starting position. Refactoring this would be a major hurdle. In what way does this limit your usage?
It is not very convenient if the origin of the coordinate system of the grid is located outside the grid. I have to adjust the coordinates myself; and the adjustment formula is not obvious. I just calculated the differences for a few sizes. It is not a very big issue for me, since I don't use many different grid sizes, but for some users it might be, I think.
This was just an improvement suggestion. If it is really too much of refactoring, maybe it does not worth it. On the other hand, I think it should not be too difficult to add a condition to those Coordinate.getGrid_()
methods and return adjusted values in case of the grid layout.
Why do you have to adjust the coordinates? There is a function for fetching all the Hexagon
s and they have their own coordinate which you can use when drawing. Is there some use case I'm not aware of?
By coordinates I mean not pixel coordinated of the vertices of the hexagons. I mean the cube coordinate system of the hexagonal grid. For me it is much more convenient if it starts in the center, because I use the GRID_LAYOUT
. Now the origin is outside of the grid (i. e. I never get a cell with cube coordinates (0, 0, 0)).
What do you try to achieve with this? Which grid layout do you use? HEXAGONAL
? You can call HexagonalGrid.getHexagons()
in order to get all the Hexagon
objects (with their coordinate) so you don't need to query them by their coordinate.
Yes I use the HEXAGONAL
layout (sorry, I was not clear about that one). I want to take the cube coordinates of any hexagon. I will need it to map the grid to an array, so that the application knows what is located in which hexagon.
Now when I create a hex grid of size 3 (as an example) I get the following grid coordinates (I hope I remembered their positions correctly): (2, -2, 0), (1, -1, 0), (2, -3, 1), (1, -2, 1), (0, -1, 1), (1, -3, 2), (0, -2, 2). So the central square has the coordinates (1, -2, 1). I would be very helpful if it was (0, 0, 0) as it is written in the article. So I would expect the following grid coordinates: (1, 0, -1), (0, 1, -1), (1, -1, 0), (0, 0, 0), (-1, 1, 0), (0, -1, 1), (-1, 0, 1).
Of course it is possible to work with the current values as well, but the application will be harder to debug (unless I change those coordinates myself, which I do now).
I want to take the cube coordinates of any hexagon. I will need it to map the grid to an array, so that the application knows what is located in which hexagon.
So have you checked HexagonDataStorage? I think this is the one you are looking for.
Can you explain why do you need the center Hexagon
to have the (0, 0, 0)
coordinate? This seems like an xy problem to me so let's try to drill down to your actual problem.
Thank you for the information about HexagonDataStorage. It is useful to know it.
There is no problem with the central Hexagon
having an arbitrary coordinate as such, it is just that during step by step debugging it is harder to get oriented where my current cell is located. It is just a suggestion, not something urgent to consider.
Oh, I see. So do you think that debug mode would be useful? It is definitely doable and it won't mess with the coordinate system. There is also an example project hexameter.example.swt
which has examples for visualization.
Yes, I think that debug mode might be useful. Thank you very much for support.
Can you open an issue with your suggestion?
Yes. I did it.
It looks like when
HexagonalGridBuilder
hasGRID_LAYOUT
set, the origin of the grid coordinate system is somewhere on the top left (when callingcoordinate.getGrid_()
). It would be easier for the user if the origin of the grid's coordinate system started in the center (as mentioned here).