pythonarcade
Feature: relative position helpers
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 😅
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.
@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.
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?
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