Add Vector[234]i structs
Posted Monday, 6 July, 2009 - 20:33 by sharoz| Project: | The Open Toolkit library |
| Version: | 1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | open |
Description
Per Fiddler's suggestion, the struct will be a minimal implementation like Vector[234]h.
The purpose for adding these structs is to make storing and passing shader uniforms consitent for ints and floats.
Comments
#1
I've been toying with ideas for a roguelike game recently, written with OpenTK and using OpenGL acceleration, jotting down ideas for program structure (I learnt some valuable lessons about planning the structure FIRST while working on LinkSphere).
I realised that a Vector2i struct would also be pretty useful for specifying entity positions on an x,y grid of discrete squares.
#2
Entropy: Why don't you create a simple EntityPosition structure/class yourself? The operators can be overloaded in C# so it will be really simple to use.
#3
Objarni: Yeah, I've written the bare bones of one (named Vector2i). It does occur to me that my "Length" property (which returns the distance in tiles) isn't really a length at all. I like your suggested name more though, as it's more accurate and properly differentiates between OpenTK's Vector classes and my own.
#4
There is a distance measure for tiles called "Manhattan distance" (from how far it is to travel with a cab in New York; Manhattan is structured like a grid). It is just the sum of the number of horisontal- and vertical steps one has to take from position A to position B. Maybe that is a more relevant distance in your game, instead of the geometrical distance (pythagorean distance)?
#5
Never heard of the term "Manhattan distance", but EntityPosition.Length currently returns the length of the longest (x,y) component. This makes sense within context, as diagonal travel between tiles is possible.
#6
Postponing until after the 1.0 release.
#7
#8
I have got Vector2i and Vector2ui structs derived from Vector2 struct. Derivation method was:
- any existance of Vector2 is replaced by Vector2{u}i and member types are changed accordingly
- obsolete members are removed
- length or normalization methods are removed
- rotation and or transformation functionality is removed
- division is implemented as integer division
- uint version does not contain negation properties (perpendicularX, operator- etc)
if these are OK then i can manipulate 3/4 versions too. If not, lets negotiate:)
#9
The main question is, do we really need operators for integer vectors? Considering that most methods other than are completely meaningless (e.g. dot product returning an integer), I think it would be best to treat the structures as simple containers like treat half-precision vectors (Vector2h).
What do you think?
If we do this, you'd either have to cast to float/double vectors to perform calculations or use extension methods to add the operators you need directly to the structures. Actually, I think the latter might have been a good design for the whole math namespace (dumb containers + extension methods) but it's a little late for that now.
#10
You are right about dot functionality. I was not sure about that when i was pruning functionality. I agree with you about having these as pure containers. However it is nice to have add/subtract methods for offsetting values as if it is a 2D point or size indicator. Or is it more natural to have Point Size Rectangle structures like Drawing namespace?
#11
It's mostly a matter of reducing duplication and simplifying maintenance. Keeping the documentation and code in sync is already a nightmare (fixes have to be kept in sync between Vector2, Vector3, Vector4, Vector2d, Vector3d, Vector4d, two overloads each) and I don't want to imagine how things would be with twice as many structures...
#12
I have pruned the multiply/divide/dot functionality, copied and expanded for 3/4 versions. Plus, i have attached a file named IntegerVectors which contains the no-operators version of the vectors
note: I need; equatable for generic equals functionality, ToString method for ease of debugging (VS parameter preview), GetHashCode for dictionary usage. So I kept them. I was not sure about static fields, but they were really nice for floating point versions by ease of initialization.