Skip to content

Reinvent the Rectangle, or The First Step Towards Rectangle Unification. #2088

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

Merged
merged 92 commits into from
May 25, 2024

Conversation

DigiDuncan
Copy link
Collaborator

@DigiDuncan DigiDuncan commented May 22, 2024

Take that, Thales of Miletus.

For years, Arcade has suffered from Rectangle fragmentation. The GUI, GL, Camera, draw commands, they all redefine and reinvent the rectangle. Need proof? We have proof. But why have many rectangle when one Rect do trick?

With Rect, you can:

  • Get every side, vertex, and size you'd ever want
  • Reorient and resize the Rect to your heart's content
  • Align it in frankly an absurd amount of ways
  • Constrain and expand the heck out of it
  • Union and intersect it with other Rects (now with bonus | and & support)
  • Find if points are in and on them
  • Turn them into GL-friendly (and even GL-unfriendly!) tuples

They have a beautiful __str__ method, backwards-compatible aliases, dead-simple property names, and implement every way rectangles were used in the library.

You can create them from **kwargs, or using one of several DX-friendly helper methods, including LRBT, LBWH, XYWH, XYRR (you're welcome, @einarf!), and Viewport (you're welcome @DragonMoffon!)

And they're fast. All eights values are pre-calculated on __init__ (despite only needing four values to create), and they subclass NamedTuple, so dot-access is Sonic-level fast.

Immutable. Extendable. Human-usable.

Merging in this PR allows a full rework of every rectangle in Arcade, making them easy to use for contributors, developers, and end users.

And as a bonus, it cleans the heck out of draw_commands.

@benjamin-kirkbride
Copy link
Collaborator

Could we get a mutable rect as well?

@eruvanos eruvanos requested review from einarf and eruvanos May 24, 2024 20:09
@eruvanos
Copy link
Member

Just agreed (with @DigiDuncan) that RectInt should be removed after we merged this huge PR.

@eruvanos
Copy link
Member

Could we get a mutable rect as well?

Right now we stick to the immutable version only. From my point of view, the convenience benefits are not big enough to introduce a second Rect option, which is mutable.

@eruvanos
Copy link
Member

So summary:

I am fine with the PR. @einarf @pvcraven please give feedback what you think about the naming of the Rect constructor functions (XYWH, LBWH, ...) being uppercase.

I would merge the PR over the next day, if you give feedback afterwards. We can still do it in another PR.

Background: The camera changes are blocked and they are one of the major points holding us back from 3.0 so I would like to unblock them.

@eruvanos eruvanos removed the request for review from einarf May 25, 2024 13:49
@eruvanos
Copy link
Member

@DigiDuncan Can you check, if you can make the PR mergable?

@eruvanos eruvanos merged commit 66ee3b9 into pythonarcade:development May 25, 2024
8 checks passed
@DigiDuncan DigiDuncan deleted the get_rect branch July 3, 2024 23:35
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.

5 participants