`Direction` not consistent with bevy screen-space coordinates
uvizhe opened this issue · 11 comments
Bevy 0.11 has changed a coordinate system (inverted Y) for cursor position.
This leads to Direction::Top
appears at the bottom.
Here is a patch for hex_grid
example to showcase the issue: patch.txt.
diff --git a/examples/hex_grid.rs b/examples/hex_grid.rs
index 5177783..1a57efb 100644
--- a/examples/hex_grid.rs
+++ b/examples/hex_grid.rs
@@ -175,6 +175,14 @@ fn handle_input(
.entity(entity)
.insert(map.selected_material.clone());
highlighted_hexes.selected = coord;
+
+ let top = coord.neighbor(hexx::direction::Direction::Top);
+ if let Some(entity) = map.entities.get(&top).copied() {
+ commands
+ .entity(entity)
+ .insert(map.half_ring_material.clone());
+ highlighted_hexes.selected = top;
+ }
}
}
}
Hi !
What version of hexx
are you using? #74 updated the way the examples retrieve and convert the pixel coordinates to the world coordinates with bevy
0.11:
- let pos = pos - Vec2::new(window.width(), window.height()) / 2.0;
+ let pos = Vec2::new(pos.x - window.width() / 2.0, window.height() / 2.0 - pos.y);
Therefore since 0.9.0 all 2D examples should behave correctly, hex_grid
included
Hi,
I run this on HEAD on main. So it's 0.9.1 and bevy 0.11.
Hmm, yes, I remember I've seen the change in pos
calculation. Not sure what's the cause of the problem then.
I think I misunderstood the issue, I'm going to try with your addition.
The direction orientation is a concept inner to the heagonal coordinate system like an orthogonal 2D vector could be (0,1) and still point down on screen if the camera is upside down.
Maybe the camera is upside down, which I would need to fix, or the way the grid is generated is inverted, which I should fix too.
@uvizhe Did you try with previous versions like the 0.8.0? The problem could be unrelated to the bevy change
Just checked it. With 0.8.0 (and bevy 0.10.1) the issue is still present, so my guess that it's related to coordinate changes was incorrect.
I think it's more likely the camera than the grid as the latter was my first assumption and I looked at my grid coordinates - it was fine (on pointy-topped rectangle X increases from left to right and Y from bottom-left to top-right)
It seems that the fact that Direction::Top points to (0, -1) is done on purpose, Direction::Bottom points to (0, 1)
I'm not sure why I made it this way, it may be a mistake
I think directions should be renamed to stuff like Direction::X
, Direction::NEG_Z
, etc to avoid this kind of inconsistencies
It seems that the fact that Direction::Top points to (0, -1) is done on purpose, Direction::Bottom points to (0, 1) I'm not sure why I made it this way, it may be a mistake
Maybe the purpose was to be consistent with Bevy coordinate system? Now, that UI and all other parts use the same coordinates it's okay to use convenient Top, Bottom, etc.?
Maybe the purpose was to be consistent with Bevy coordinate system? Now, that UI and all other parts use the same coordinates it's okay to use convenient Top, Bottom, etc.?
I think I made it based on this, which is fine but I think the directions should be rename to use coordinate axis instead of named directions and avoid this issue
@uvizhe After running some tests the issue is simple:
Hex
considers that positive y
goes "down" (for flat topped, otherwise it goes "down right") in ortogonal system
This is correct inside of the hexagonal system but confusing when using pixel/screen coordinates when the standard is y
up.
But when converting Hex
to pixel/screen/world the y
axis is actually going up, meaning somewhere something is inverted.
Therefore AFAIK there are two choices:
- Fix the inverted axis (maybe the conversion is wrong)
- Rename the directions so that
Direction::Top
is actually towardsy
instead of-y
I made hex_grid
example show hex coordinates (see the patch2.txt) and I see that on flat hexes Hex.y
raises from bottom to top. This contradicts to what you say and to what I see in that article.
Also the article itself looks confusing, because actual coordinates in examples do not correspond to directions of axis arrows.
I think I found out what the issue is, for rouding hex (Hex::round
) I use this method instead of the redblobgames method, and it seems to use a different orientation, I'm getting confused but I'm getting closer to the issue I think.
Btw I think adding coord text to the hex_grid
example is a good idea I will implement this