Skip to content
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

Feature: relative position helpers #2051

Open
wants to merge 6 commits into
base: development
Choose a base branch
from

Conversation

DigiDuncan
Copy link
Contributor

Really basic relative position helpers for a Window.

Adds two functions, relative() and absolute(), which allow to convert to and from screenspace coordinates.

Inspired by my adventures in Ren'Py.

If there's any issue with this, I apologize, my blood sugar is off today 😅

DigiDuncan and others added 5 commits April 6, 2024 18:39
* Normalized -> fractional since we aren't clamping

* Variable name and style tweaks (redundant parens can go)
arcade/application.py Outdated Show resolved Hide resolved
Comment on lines +918 to +927
def absolute(self, fractional_pos: tuple[float, float]) -> tuple[float, float]:
"""Convert a relative fractional pair to absolute screen pixels.

As in the rest of arcade and OpenGL, the default coordinate system
places the origin at the bottom left.

:param fractional_pos: A position where the x and y are fractional
values of the window size.
:returns: A tuple of absolute pixel X and Y relative to bottom left.
"""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This docstring just seems to academic and lacks contex/example. It's unclear what "fractional pair" is. Also unsure is the method name itself is clear.

Comment on lines +932 to +936
def relative(self, pixel_pos: tuple[float, float]) -> tuple[float, float]:
"""Convert absolute screen pixels to a relative fractional pair.

:param pixel_pos: a tuple of X and Y pixel positions within the window.
:returns: A tuple of fractional X and Y relative to the bottom left.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This docstring just seems to academic and lacks contex/example. It's unclear what "fractional pair" is. Also unsure is the method name itself is clear.

@einarf
Copy link
Member

einarf commented Apr 7, 2024

If the idea here just being able to express/convert 0.0 -> 1.0 screen coordinates into pixel coordiantes regardless of aspect ratio? Is this really a common use case in arcade? I think this change lacks contex and more explanation.

@DigiDuncan
Copy link
Contributor Author

@einarf

If the idea here just being able to express/convert 0.0 -> 1.0 screen coordinates into pixel coordiantes regardless of aspect ratio?

Yes. This is mainly for UI positioning or thing meant to be "pinned" to the sides of the windows.

For example, if you have a 1280x720 window, and you want something in the dead center, (0.5, 0.5) <-> (640, 360)
what this means is it doesn't matter how much you resize the window, you can always say window.absolute((0.5, 0.5)) and get the correct place to place your element. Or if I want something to be 95% to the right at all time, window.absolute((0.95, 0.5)), etc.

It's based slightly off how Ren'Py handles positioning; it makes these calculations screen dimension-agnostic.

@pushfoo
Copy link
Member

pushfoo commented Apr 8, 2024

If the idea here just being able to express/convert 0.0 -> 1.0 screen coordinates into pixel coordinates regardless of aspect ratio?

TL;DR: Not just 0.0 to 1.0 since it's useful for OOB events

When I asked Duncan about whether this is intentionally unclamped, he pointed out that it's intentional. I can see the value of this since values may fall outside window and other bboxes, especially during mouse drag events.

This means "normalized" not quite right in my eyes. "Relative" is also too vague and misleading since it's not actually encoding the relative position to anything but the origin.

Is this really a common use case

TL;DR: I think it would be if we built it out, especially for the UI

Percent-like layout would be useful for general UI layout imo. I'm not sure of how to handle it from an API standpoint yet, but I see its consistent usefulness in CSS percent units.
In our case, I think the decimal form would be more useful since we already seem to have axis aligned UV values for UI element textures. Those area all quads anyway, right?

@einarf
Copy link
Member

einarf commented Apr 10, 2024

Definitely not againts it, but method names and docstrings are very vague. I had to actually read the code to even start understanding what the methods are about. A little more text and an Example:: block is a helpful start.

"There are only two hard things in Computer Science: cache invalidation and naming things" -- Phil Karlton

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants