Issue with GuiElement positioning

    Is it just me or I am a bit confused with relative size and positions of GUI elements?


    First, positions are from the bottom left corner of the screen (i.e. x=0, y=0 is the bottom left corner of the viewport), which is counter intuitive with the top left positioning of just about every UI managers. I understand that this is an OpenGL issue, but why not translating these values (i.e. inverting the Y's) instead of making it awkward for the plugin developers?


    Second, PivotPosition is also reversed. Where PivotPosition.BottomLeft makes a container align from the top left corner! If the Y positions were reversed, these values would be more accurate.


    I understand that this will break a few plugins implementing GuiElement, but should this be kept much longer and break more things down the road? Unless the system is set with a right-to-left (RTL) locale (e.g. Arabic), all coordinates should be from the top left corner of the parent viewport, meaning that 0, 0 is always the pixel at the top left of the viewport. Therefore :

    • PivotPosition.TopLeft (default) sets the element at position x and y (currently, it is set to parentHeight - y and height goes up vertically)
    • PivotPosition.TopRight sets the element at position x - width and y (currently, it is set to parentHeight - y and height goes up vertically)
    • PivotPosition.BottomLeft sets the element at position x and y - height (currently, it is set to parentHeight - y - height and height goes down vertically)
    • PivotPosition.BottomRight sets the element at position x - width and y - height (currently, it is set to parentHeight - y - height and height goes down vertically)

    Great things can be done with the current API (even if other issues do exist with the GUI API), and positioning should be fixed.

    Quote from LordFoobar

    First, positions are from the bottom left corner of the screen (i.e. x=0, y=0 is the bottom left corner of the viewport), which is counter intuitive with the top left positioning of just about every UI managers. I understand that this is an OpenGL issue, but why not translating these values (i.e. inverting the Y's) instead of making it awkward for the plugin developers?

    OpenGL handles the screen coordinates this way, i.e. 0|0 is the bottom left corner of the screen. Without taking into account that DirectX handles this differently, I'm not sure if the OpenGL way isn't even more intuitive at least for newcomers: people would probably consider the screen being a 2-dimensional coordinate sytem (even though this is technically wrong), and in school we learn that the origin of a 2d coordinate system is in the bottom left corner.


    It's a pity that there are differences out there how screen coordinates are handled, but since RW is an OpenGL application, I'm not sure if it's a good idea to change the coordinates. Especially since changing that would break every existing plugin which uses gui elements =O


    Quote from LordFoobar

    Second, PivotPosition is also reversed. Where PivotPosition.BottomLeft makes a container align from the top left corner!

    Hmm... I just checked it and it works as intended 8| The pivot position sets the position of the pivot of the particular gui element, e.g. when changing it to BottomLeft, the bottom left corner of the gui element is used for the pivot position (i.e. the actual position of the gui element refers to the pivot position).


    Example:

    Java
    GuiPanel p = new GuiPanel(0.5f, 0.5f, true, 300, 200, false);

    p.setPivot(PivotPosition.BottomLeft);

    player.addGuiElement(p);


    This code (PivotPosition BottomLeft) gives this result (as intended):


    Changing the PivotPosition to TopLeft, we get this result:


    Changing it to BottomRight:


    And changing it to TopRight:


    Did you encounter a different behavior with other gui elements?

    AFAIK OpenGL is the only system that handles coordinate this way.

    • Any terminal handle position 0,0 as the top left character slot, i.e. from top-left to bottom-right
    • WPF / Windows Form, Xorg / Wayland, etc. all handle from top-left to bottom-right just the same
    • CSS handles absolute coordinates from top-left to bottom-right just the same
    • JavaX / AWT / Swing handle position 0,0 as the top left pixel to the bottom right one, exactly as the others do.

    The point is, while it may make sense for 3D coordinates, 2D is usually for UI and other platformer games, and except some scrolling shoot'em-up, pretty much all games play from top to bottom and left to right (because of gravity and how the great majority of the world read from left to right; it's easier for the eyes and hand coordinates).


    Of course, mathematics use the bottom left coordinate of a 2D plane as origin, sure! But, then again, art uses yellow blue and red to mix colors, too!


    My point is, it is awkward to lay out controls on a vertical axis from bottom to top... then read these control from the other way around! And the answer is simple : negate the Y coordinate to make it more convenient for UI design to lay the controls! Or am I really the only one finding an issue with this?


    So what if it breaks a handful of plugins? What about the dozens that will follow and be stuck with the design??

    Quote from LordFoobar

    Or am I really the only one finding an issue with this?

    tbf I have no idea why you are finding this an issue. It is really not that hard to figure out where the coordinates are, just a matter of willingness to get used to a different system.


    The most straightforward way to design anything imo is bottom to top and left to right, I find the top to bottom to be the "weird" way :/

    Quote from Minotorious

    tbf I have no idea why you are finding this an issue. It is really not that hard to figure out where the coordinates are, just a matter of willingness to get used to a different system.
    The most straightforward way to design anything imo is bottom to top and left to right, I find the top to bottom to be the "weird" way :/

    What plugin have you coded that uses the GUI API?


    Also note that nearly half of the the listed plugins that do have a GUI are written by Miwarre... And only 2 or 3 others are significant enough that a change would break their UIx. All the others are basically only labels and single menu panels.

    Quote from LordFoobar

    The point is, while it may make sense for 3D coordinates, 2D is usually for UI and other platformer games, and except some scrolling shoot'em-up, pretty much all games play from top to bottom and left to right (because of gravity and how the great majority of the world read from left to right; it's easier for the eyes and hand coordinates).

    Basically the UI is a 3d coordinate system (with z representing the depth value, or more precisely, the rendering order), since the UI is handled by OpenGL. Reading from left to right makes sense and we have no intentions to change that, but I'm still not sure about flipping the Y axis :| I think the best thing is to stick to the OpenGL conventions.


    Especially in the long run it's our intention to offer shader support for the API, probably also for GUI elements, but at least support for post-processing effects (so people can manipulate the current screen which is rendered to a texture). If we really change the Y axis for GUI elements, this would result in *a lot* of confusion, since shaders still have to use the OpenGL convention...


    Quote from LordFoobar

    BTW: nevermind also that the mouse coordinates are using the same screen coordinates (i.e. 0,0 is the top left corner) But, hey! whatever, right?

    What do you mean exactly? I just tried the player.setMouseCursorCoordinates() function as well as the getters of PlayerGuiElementClickEvent, all of them use correct coordinates (i.e. 0|0 is the bottom left corner) ?(

    Quote from LordFoobar

    What plugin have you coded that uses the GUI API?

    One that you shouldn't be aware of yet. :P Not public as it is still in development.

    Quote from LordFoobar

    Also note that nearly half of the the listed plugins that do have a GUI are written by Miwarre... And only 2 or 3 others are significant enough that a change would break their UIx. All the others are basically only labels and single menu panels.

    I would never use another player's plugin as the base for mine. One cannot be sure that the other player will keep updating their's for mine to work. Thus I only use the RW GUI whenever I need to display something.


    The biggest problem we will have on our server if the RWGUI is changed is that the teleport plugin will stop working (since the dev has stopped updating it) so I will be forced to write a new one, and I don't want to have to do that atm.

    Quote from LordFoobar

    But, hey! whatever, right?

    Exactly. Whatever, will get used to it. As an engineer I have learnt to get used to the way things are no matter how weird or counter intuitive I find them and not "complain"/expect the minority to change when something is just different from the majority of other similar things.

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login