Mac Ryan wrote:
The behaviour that I envisage would be an
optional keyword argument ``scale=1.0`` for rectangles (and surfaces).
I would say the transformation should be an attribute of the
surface, not something that you pass into drawing calls. Also
it should allow for both scaling and trans
Yeah,
I read the papers regarding A* realistic movements and the ones concerning the
steering behaviors. At the moment, i divided my circuit into area and this is
how i do : i randomly choose one point per area for each ai and i find shortest
path between those waypoints using A*. This way i ha
On Sat, 24 Sep 2011 14:39:31 -0500
Jake b wrote:
> Are you using numpy?
No, since I don't have to do very complex or loads of operations I went
with euclid... but I'd be interested in knowing if you have suggestions
involving numpy, nevertheless.
/mac
Note: Learn how to use vectors. You will need this for steering, and
movement. (You technically don't, but it's much simpler)
The *very best* tutorial to A* pathfinding :
http://theory.stanford.edu/~amitp/GameProgramming/ ( Great diagrams )
These are relevant for your racing, and terrain.
Making
Are you using numpy?
--
Jake
Thank you for all your answers. I condensed my reaction in a single
mail:
Julian Marchant wrote:
> What is the purpose to having calculations done with a size that's 10
> times larger? If it's just precision, the solution could be simply to
> use floats for the calculations and convert to ints a
