What is UP for rock climbers hanging upside down,
when they are chatting on their phone,
which points towards the horizon,
whilst they live in Australia? ;)
( @Ian... give in to the temptation... )
Thanks Victor, those are some good notes.
And I guess some of them will take some time to figure out how to handle them nicely.
1) Ok, right. I'll add that to the list.
http://www.pymunk.org/en/latest/_modules/pymunk/vec2d.html#Vec2d.normalize_return_length
That's useful because...
when you want to keep the length (as a speed),
'normalize_ip' currently returns None.
So it might be nice to return the length(magnitude) there?
'normalize` returns a copy of the vector.
2) scaling back up from 0 does indeed seem hard.
Would it need to be only after it was scaled down?
Perhaps adding the last value would be useful.
But then, there are many ways a vector can come to be at zero.
3) perhaps some assumption could be used about screen->world coordinates could be baked in.
Or some property of the vector,
vec2(0, 1).asGL??? -> vec2(0, -1)
Swizzle convention?
vec2(0, 1).xY -> vec2(0, -1)
Not sure really.
draw.circle says,
"Give me the coordinates in pygame screen coordinates? Please." -> (0, 1)
4) oh yes, draw functions. Very good point.
Automatic rounding in the draw functions seem a good idea.
I'll include drawing a circle in my example I'm writing,
and perhaps modernise circle drawing first.
What would a pygame.draw.vector2 look like? draw.vector3?
5) I didn't try benchmarking with pypy.
I expect they'll have similar performance to other pygame C types like Rect.
Not sure if they have optimized keyword arguments(METH_KEYWORDS),
as much as they have METH_NOARGS and METH_VARARGS.
I'm going to the pypy sprint in Leysin, and should get a benchmark ready by then.