[TRACKER] Refactor math code and add integer vector types

[aaronfranke]

I plan to make separate PRs for each item on the list. Each change (mostly) requires the one before it, but I believe that each change is justified on its own without taking into account future ones (following the from one working state to another working state philosophy).

I won't work on future items until current PRs are merged (since they need past items).

• [x] Split up math_2d (#18096) (3.1)
• [x] Rename Point2i to Vector2i as suggested (also in #18096) (3.1)
• [x] Add a Vector3i type similar to Vector2i (#36436) (4.0)
• [x] Expose Vector2i and Vector3i in GDScript (#36436) (4.0)
• [x] Add Vector2i and Vector3i to C# (#36756) (4.0)
• [x] Add Vector2i to relevant classes (such as TileMap and GridMap) (4.0?)
• [x] Investigate other places Vector2i and Vector3i would be useful (4.0+)

The below discussion may not reflect the above points, as I've edited this post over time.

[groud]

Please wait for a proper PR review of #18096 before doing all this work. I personally believe most of those changes are not desired.

[PJB3005]

Position2 might be a bit of a handful to write, so Pos2 might be a good idea too.

[aaronfranke]

I had considered Pos2 and I figured it could be ambiguous as well, but then again, what else could Pos mean except for Position? We may end up switching it to Pos2 instead, if it's desired.

Edit: Seems to not be desired.

[akien-mga]

Position2 might be a bit of a handful to write, so Pos2 might be a good idea too.

Given that we changed all the 2.x API from *pos* to *position*, I don't think that would be consistent :)

[groud]

I don't get why you think a "Point" induces an integer positioning. The mathematical definition of a point is basically a position in space. You say "a point on the grid" but "a position on the grid" has exactly the same meaning. I think Point2 and Point2i are understandable and explicit enough.

Regarding other changes, they need reduz's input. I suspect there are reasons for those classes not being exposed to GDscript/c#.

[aaronfranke]

I mean, I could make "Position2i" a typedef for integer points, but here's my thought process:

• I don't like one name for two things. Point2 should be changed to Position2 for sure.

• Then we need a name for integer points. For the reason above, plus the fact that it doesn't behave like a vector, I don't think Vector2i is a good choice at all. Point2 seems like a good choice.

  • I get that "point" can mean "any point in space" but every programmer knows that's what "vector" is for.

  • For the example use case of dictionary keys, it's hard to have exact floating-number points but integers can easily refer to exact points (on a grid).

  • Do you have any other suggestions aside from having i at the end? I think it's inelegant. Adding i is explicit and specific, but we don't write Vector2 as "Vector2f" either. I think people should be able to tell what the type is from just the name and number.

  • The existing Point2 being freed up means we shouldn't need to specify i, but even if we keep the name Point2i I'd still prefer Point2 changed to Position2

[groud]

To understand clearly, this is how things are done now:

struct Vector2 {
//...
}
typedef Vector2 Size2;
typedef Vector2 Point2;

struct Point2i {
//...
}
typedef Point2i Size2i;

for me, making things consistent would just be:

struct Vector2 {
//...
}
typedef Vector2 Size2;
typedef Vector2 Point2;

struct Vector2i {
//...
}
typedef Vector2i Size2i;
typedef Vector2i Point2i;

So for me:

• there are no sufficient reason to change Point2 to Position2, they mean exactly the same thing to me and Point2 is faster to write.
• I don't understand at all the difference you make between a Vector and a Point/Position. Even wikipedia does not make the difference: https://en.wikipedia.org/wiki/Position_(vector).

Do you have any other suggestions aside from having i at the end? I think it's inelegant.

That's where I disagree. I have no problem with that. There are no mathematical term to define a point/vector/position/size that is defined on an integer space, thus adding a "i" in the end makes more sense than any other solution replacing one of the current Point2/Position2/Vector2 by a integer version. As any of those term can be understood as float or integer, doing so would definitely lead to more confusion.

[aaronfranke]

I'm not saying that a position isn't a vector. I'm saying that integer-math "vectors" lose many of the properties that mathematical vectors have, such as normalization (only possible when aligned to axis) or rotation (only possible with 90-degree multiples). So "Vector2i" could be misleading.

The distinctions are that "position" is more specific than "vector" or "point" which can be ambiguous, and "vector" is never used to describe grid points but "point" is, so "point" for integers seems appropriate if we want to have unique names for each type (I do, you don't).

My proposal would be:

struct Vector2 { 
//... 
} 
typedef Vector2 Size2; 
typedef Vector2 Position2; 

struct Point2 { 
//... 
} 
// typedefs optional, I personally don't want them, "Size2i" defeats purpose of unique names

[groud]

Yeah obviously, you can't do the same thing in the real numbers space than in the integer one.

But this is not the question here, the question is how should we name those objects. For me, using "Point2" (or "Position2") for integers and "Vector2" for floats is even more misleading than having "Vector2" for float and "Vector2i" for integers. As no substantial distinction can be made between point/vector/position/size, the "i" at the end seems a correct solution to distinguish between what is integer-based or not. We could name it something like IntegerVector2, IntVector2 or even Vector2Int, but since it's a commonly used type I think the "i" is probably enough.

[aaronfranke]

Even if we call integer "vectors" Vector2i. I do still think that "Position2" is a better typedef name than "Point2". Positions are called "position" in most other places in the code.

[romlok]

Since it'd not be dealing with a continuous coordinate space, might Discrete2 be an option for the name? Even though "discrete" does not necessarily mean only integers in mathematical terms, Godot primarily targets game developers, not mathematicians. :)

---

As to the existing use of Point2 and Size2, neither of them are exposed to the GDScript side of things, and developers seem to do fine with positions and sizes being stored as mere Vector2s.

Personally, I don't see a need for Point2 and Size2 to exist as aliases of Vector2 if annotating variables is their only purpose. IMO, If a variable name isn't descriptive enough then the variable name should be made more descriptive. And FWIW, all the variables I've seen where these are used seem to be descriptive enough already!

[BBric]

Pixel or Cell or PairInt for Point2i ?

[aaronfranke]

@romlok @BBric Good suggestions. I like the word Cell, it fits well with the use cases described here https://github.com/godotengine/godot/issues/3286 of using these integer point classes with dictionaries/maps (where floats are unsuitable). If we decided to change Point2i to Cell2 then I would be happy with that change. The big thing is that I like unique names - I dislike "Vector2i" because it looks just like "Vector2".

But I don't like the names Pixel (sounds like something to do with images) or PairInt.

Side note, some other projects use Point to mean integer points, such as MonoGame's Point.cs.

[aaronfranke]

Assuming we go with "Cell" as the integer point/vector/whatever name, how about this?

struct Vector2 { 
//... 
} 
typedef Vector2 Size2; 
typedef Vector2 Point2;  // Or, Position2

struct Cell2 { 
//... 
} 
typedef Cell2 Size2i; 
typedef Cell2 Point2i;  // Or, Position2i

[BBric]

'Position' is good too, it remains geometrical, but maybe humanly slightly more specific, thus better suited for integer coordinates...

[aaronfranke]

It sounds like we're going with "Vector2i" based on Reduz's response here.

[Anutrix]

What's the status now?

[aaronfranke]

@Anutrix https://github.com/godotengine/godot/pull/22205 will be merged after 3.2 is released, and I plan to finish this work by 4.0.