Hi!
I guess we could talk any language to death on speed, but being smart on
how to speed up the existing one is the best approach.
As I said, Ian could use the example I gave him and the other comments
which he has already said he does. The distance instead of the square root
for that is meaningless when comparing. But when you want to find the pixel
(x,y,z) then you do have to use the square root to get the outer edge exact
point.
So the object has a vector, speed and direction. That direction has an
intersection point, so the triangle formed also merges between the object
centers. So the line drawn between object centers will intersect a location
on each surface at some point. So, monitor that point by changing it to a
key in a dictionary: key = str(x)+str(-y)+str(-z)
Those points, only 2, are changing as the objects approach each other
based on that angle drawn with the vector.
The only thing that is a variant besides the triangle being formed with
the vector is the objects outer edge, for if it is an irregular shaped
object, then you have some work to do to calculate that point. Maybe the
only static array is the objects actual shape in memory which can give you
the distance based on the radii drawn to it from the object center...
So any person can speed up there game by just using some simple trig...
Bruce
True, although that constant is often on the order of 20, and 40 FPS is
a lot different than 2FPS.
--Mike
Casey Duncan wrote:
> On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote:
>> OK, my point here is that if C languages can do it, Python should be
>> able to too. I think all of this answers my question about why it
>> isn't...
>
> C can do what? C is, at best, a constant time improvement in
> performance over python. A bad algorithm in Python is also a bad
> algorithm in C.
>
> It's all well and good to think that Python should be as fast as C,
> but no one is going to take you seriously unless you have a specific
> proposal, preferably with an implementation that proves its merit.
> Otherwise it's just wishful thinking.
>
> But the larger point is that making things run faster is not an
> panacea, reducing the algorithmic complexity is the best solution.
> Make sure you have the best algorithm before you worry about reducing
> the constant time factors.
>
> -Casey
>
