[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] API draft for vector type
On Apr 27, 2009, at 6:16 PM, René Dudfield wrote:
Would be nice if the vectors storage of things could be anything
underneath. This would be useful to allow them to use pygame.Rect
or numpy.array underneath. This means they can refer to a batch of
vectors, but also operate only on a single vector at a time.
+1, though there are performance vs. generality tradeoffs to be made.
On the general side, a vector class could assume the underlying
storage supports __getitem__, but the performance of this would
suffer, I think too greatly. On the performance side, it could just
have a pointer to an array of floats that it wraps with the vector
api. I used this strategy with Lepton and the performance is great,
but it is inflexible for the storage, and probably not very practical
for totally general use across different storages.
Wondering about why only 3 element vectors? 2,3, and 4 element ones
are common? Is there a way to make a combined 2,3,4 type?
Most operations can assume the higher dimensions are always zero, or
the length could just be variable. But in either case the code would
be slower than it would strictly need to be, since many operations
would do more work than needed or would require loops where they would
not be required for single purpose 2D, 3D or better vectors.
What number types are used? eg, can you have a float vector, a long
vector, an int vector? Any python number? A uint8 ?
Seems to me like the most general number type would be a double, as it
could comfortably support a wide range, does not generally have
resolution issues like a 32-bit float can and performs well on modern
hardware. It would also give consistent results compared to a python
float, which is nice.
I'm not sure what the use-case is for ints or (python) longs, the
latter would probably gain little by being coded in C compared to pure
python. Even in sprite-based 2D games, I find integers to be far too
coarse for vector math, and operations like normalize become basically
impossible.
If you support multiple vector numeric types, than you have to
confront a combinatorial explosion of type conversions and either
duplicate, templatize or generalize the code in such a way that you
trade either performance or maintainability or both.
-Casey