The Rect, Pt. II: The Rect-oning and the Vec-oning

[DigiDuncan]

Don't call it a comeback.

Welcome to the new stage of Rect: integration. We put Rects anywhere that mattered except GUI, we'll work on that with @eruvanos, and it makes the library code and the end-user experience so much nicer. See for yourself:

• Rect
  • Added Rect.distance_from_bounds()
  • Added position_to_uv() and uv_to_position()
  • Added point in rect support for Rect
  • Added * and / support for scaling relative to (0, 0).
  • Added bool() support (area is not 0)
  • Added support for round(), floor(), and ceil()
  • Added .area property
  • Functions expecting Vec2 now accept Tuple[AsFloat, AsFloat]
  • Improved docstrings
  • Fixed .viewport
• Added type aliases Point2 and Point3
• Camera
  • All camera functions now take Point, Point2, or Point3 where points are expected
  • All camera functions return Vec2 or Vec3 as expected
  • Viewport has been removed from the ProjectionData Protocol
  • Projectors now accept a viewport Rect, and a Scissor Rect
• Added Rect and it's constructors, Vec2, and Vec3 to top-level module
• Added Texture.draw_rect()
• Added BasicSprite.rect
• Added Section.rect
• Added Window.rect
• Added SpriteSolidColor.from_rect()
• Added NinePatchTexture.from_rect()
• Remove IntRect, FloatRect, RectList aliases
• Rename the old Rect in arcade.GUI to GUIRect
• Most things that were returning Tuple[float, float] now return Vec2, same for Vec3
  • This includes BasicSprite.scale_xy, though it's name and functionality I believe should be replaced with the suggestions made in Name scale properties on Sprites to things that make sense #2021

[DigiDuncan]

Added Window.rect and Rect.position_to_uv() and Rect.uv_to_position(), which technically contains the functionality contained in #2051, though I'd argue the DX (developer experience) found in that PR is slightly nicer.

[alejcas]

What's the reason behind having Vec2 and Tuple[AsFloat, AsFloat] coexist?

[alejcas]

Also what about typing Rect[int] or Rect[float] seems that rect sizes are always floats.

[pushfoo]

What's the reason behind having Vec2 and Tuple[AsFloat, AsFloat] coexist?

The same one was Color and RGBA255: allow people to pass non-Vec2 types for convenience.

Also what about typing Rect[int] or Rect[float] seems that rect sizes are always floats.

TL;DR: My understanding is that it's unneeded complexity.

As far as I understand, the only case where we lock to int is when we're dealing with viewport pixels. Otherwise, the main purpose of rectangles is bound checking.

If we were to add Rect[int], then we'd have ugly issues with rounding behavior. I think I once found a way for an object to become aware of what it was annotated as, but it was complex and probably slow. The alternative would be to pass in a type for rects at creation, but that's ugly.