I don’t think this is just me, or maybe that was the intention? I wouldn’t think so.
[java]
public void highlightMap() {
/*
This method is used to position a panel, sort of a tooltip, telling the user what element is under the
cursor and the quantity in kg.
*/
Vector2f mousePos = app.getInputManager().getCursorPosition();
HashMap info =
harvestMap.getHavestableInfo(mousePos);
if (info != null) {
// Mouse cursor is close to a harvestable node, inform user.
// There’s always only 1 entry, so it’s safe to use it that way.
Map.Entry printable = (Map.Entry) info.entrySet().iterator().next();
String elementText = (Integer) printable.getValue() + " kg of " + getNameFromHashCode((Integer) printable.getKey());
int x = (int) (mousePos.x - asm.getState(GuiManager.class).getScreenElement("HarvestNotificationPanel").getWidth() / 2);
/* Since the gui’s 0, 0 is (supposedly) top left y should be adjusted by -3 to move it a bit above the
cursor, but that’s not working. -3 brings the panel DOWN, not up./
int y = (int) (mousePos.y + 3);
if (x app.getContext().getSettings().getWidth()) {
if (x app.getContext().getSettings().getHeight()) {
y = app.getContext().getSettings().getHeight();
}
/ At this point with the X and Y we got above, the panel should be ABOVE the cursor’s position
because I just used Y + 3 and didn’t use the panel’s height. Thus the panel’s origin
(top left corner) should technically be 3 pixels above the cursor position. It’s not. The panel’s
lower border is 3 pixels above the cursor’s position.
This makes me think “moveTo” is doing something not conventional. */
asm.getState(GuiManager.class).getScreenElement(“HarvestNotificationPanel”).moveTo(x, y);
asm.getState(GuiManager.class).getScreenControl(“harvesteredNoteInfo”, Label.class).setText(elementText);
asm.getState(GuiManager.class).getScreenElement(“HarvestNotificationPanel”).show();
}
}
[/java]
Could it be possible to check on this? A confirmation/fix would be great.
[java]
public Vector2f eventToPosition(float x, float y) {
return new Vector2f(x-getAbsoluteX(),getHeight()- (y-getAbsoluteY()));
}
[/java]
I have added it to my local copy of Element and use it for all event related processing, passing evt.getX(), evt.getY(). Only way to stay sane.
EDIT: Just understood you are talking about screen positions, not in-element positions. Anyway, y coordinates in mouse events are opposite everything else.
@abies said:
Anyway, y coordinates in mouse events are opposite everything else.
I’m aware of that. Thing is, other methods will properly translate it to use screen coordinates instead of OGL coordinates. There’s a discrepancy here. You do one or the other all the time, not one at one point and another at another point.
@t0neg0d’s GUI has been made for one of those reasons…
Element constructor position = vector2f representing a position on the screen. For example: new Vector2f(15f, 5f); is pixel 15 from the TOP LEFT and 5 pixels DOWN FROM THE TOP. Not from bottom left. TOP LEFT.
Now that’s cleared, why when I use a method like moveTo(x,y), coordinates are in OpenGL coordinate system (BOTTOM LEFT) while the constructor is using a different system. I prefer screen coordinates, but at the end of the day I don’t care as long as it’s the same all the time.
The only time the Y coord is not flipped is when you are creating an element. I flip them in that case just so you don’t have to think upside-down while putting together your layout. Past this, I would have gone crazy trying to keep up with it.
Sooo… for mouse position to element (related methods):
screen.getMouseXY() (if you ever want to know where the mouse is currently… event or not)
element.getX() or element.getAbsoluteX() (first is relative to the parent, the other is x coord on screen)
element.getY() or element.getAbsoluteY() (first is relative to the parent, the other is y coord on screen)
similar methods for width and height.
The only time the Y coord is not flipped is when you are creating an element. I flip them in that case just so you don’t have to think upside-down while putting together your layout. Past this, I would have gone crazy trying to keep up with it.
IMO and just IMO, you should always use the bottom left as the origin as it's opengl norm. Would be more consistent with how the the pure gui node is working in the engine.
Also as madjack said, even if you choose top left, you should be consistent across the whole library.
At worst offer a convenience static tool class that does the flipping for the user that don’t want to mentally do the math.
@nehon said:
IMO and just IMO, you should always use the bottom left as the origin as it's opengl norm. Would be more consistent with how the the pure gui node is working in the engine.
Also as madjack said, even if you choose top left, you should be consistent across the whole library.
At worst offer a convenience static tool class that does the flipping for the user that don’t want to mentally do the math.
This one was sort of a nightmare to think through. The y coord wasn’t the big concern, it was when height was added that it becomes really difficult to figure out where things are supposed to be (think dynamic menu under a button). I like the idea of a utility for flipping the coords. I’m definitely going to see if I can manage to put together something that works well for this!
EDIT: the example above would be: menu.setY(button.getY()-menu.getHeight()) … very backwards way of thinking about things =(
@madjack said:
Please add those notes in the javadoc because what it says right now:
For me, screen coordinates = top left… Just saying.
At least now I know.
I will indeed. Really sorry for the inconvenience on these types of things. Eventually, they’ll all be documented well =) Or fixed in a way that easier to understand.
@nehon said:
Would be more consistent with how the the pure gui node is working in the engine.
That’s where my confusion stems since I knew only the constructor used screen coordinates. Chris had mentioned to me in another thread that internally it was still using the normal OGL coordinate system. But because of that (and I guess since nothing has ever been said about methods) I was sure everything else was translated the same way.
Anyway. Now that I’m aware of this, I’ll make the necessary adjustments.
