[pygame] Pygame 2D vector

2011-07-23 Thread sam . hacking
On the 2D vector page, http://pygame.org/wiki/2DVectorClass

It has a get_angle() function, the first line of this checks if
length_sqrd() == 0, and then returns the angle as 0. This seems
wrong to me, if the vector is (1,-1), then length_sqrd (1**2 +
-1**2) returns 0, and so the angle is returned as 0. The angle
for the vector should return -0.78... (in radians) not 0.

I believe the problem is get_length_sqrd(), I think the lines:
x = -self.x if self.x  0 else self.x
y = -self.y if self.y  0 else self.y
should be added (and the same to get_length()). I just wanted to
check if people agree, before I change the page.

I assume this function call is supposed to be faster that
math.atan2, which is why it is checked first. With these extra
lines of code, is it still beneficial to have this call in, or
just to remove the call from get_angle()?

Thanks,
Sam Bull


Re: [pygame] Pygame 2D vector

2011-07-23 Thread DR0ID

On 23.07.2011 13:03, sam.hack...@sent.com wrote:

On the 2D vector page, http://pygame.org/wiki/2DVectorClass
It has a get_angle() function, the first line of this checks if 
length_sqrd() == 0, and then returns the angle as 0. This seems wrong 
to me, if the vector is (1,-1), then length_sqrd (1**2 + -1**2) 
returns 0, and so the angle is returned as 0. The angle for the vector 
should return -0.78... (in radians) not 0.

I believe the problem is get_length_sqrd(), I think the lines:
x = -self.x if self.x  0 else self.x
y = -self.y if self.y  0 else self.y
should be added (and the same to get_length()). I just wanted to check 
if people agree, before I change the page.
I assume this function call is supposed to be faster that math.atan2, 
which is why it is checked first. With these extra lines of code, is 
it still beneficial to have this call in, or just to remove the call 
from get_angle()?

Thanks,
Sam Bull


Hi Sam

I think your math is wrong:

length_sqrd (1**2 + -1**2) returns 0 --btw this line does not make much 
sense anyway, it should be length_sqrd(1, -1)



this is not true, calculated correctly:

1** 2 + -1 ** 2  ==  1 * 1 + -1 * -1 == 1 + 1 == 2


Your mistake basically was that you assumed that  -1 ** 2 == -1 which is 
not.


And I think the check in which quadrant the point is should be done in 
the get_angle method since get_length_sqrd just returns the length of a 
vector which does not depend on the quadrant. Using atan2 might be 
simpler but could not match with the angles pygame uses (besides of the 
potentially needed degree - radians translations).


Hope this helps.

~DR0ID




Re: [pygame] Pygame 2D vector

2011-07-23 Thread sam . hacking
Well, when I type -1**2 into Python, it returns -1. If I run
1**2 + -1**2 it returns 0. So, is there a bug in Python then?
Running 2.6.6 on Ubuntu 10.10.

Removing the if statement from get_angle fixed the angle problem
for me, because of this.

On Sat, 23 Jul 2011 13:56 +0200, DR0ID dr...@bluewin.ch
wrote:

Your mistake basically was that you assumed that  -1 ** 2 == -1
which is not.


Re: [pygame] Pygame 2D vector

2011-07-23 Thread sam . hacking
Ah, I see the problem, it's doing -(1**2), you need to put
(-1)**2. And, that's not a problem for the vector class, it's
only because I modified my copy a little. OK, nevermind then.

On Sat, 23 Jul 2011 13:23 +0100, sam.hack...@sent.com wrote:

Well, when I type -1**2 into Python, it returns -1. If I run
1**2 + -1**2 it returns 0. So, is there a bug in Python then?
Running 2.6.6 on Ubuntu 10.10.

Removing the if statement from get_angle fixed the angle problem
for me, because of this.

On Sat, 23 Jul 2011 13:56 +0200, DR0ID dr...@bluewin.ch
wrote:

Your mistake basically was that you assumed that  -1 ** 2 == -1
which is not.


Re: [pygame] Pygame 2D vector

2011-07-23 Thread DR0ID

On 23.07.2011 14:26, sam.hack...@sent.com wrote:
Ah, I see the problem, it's doing -(1**2), you need to put (-1)**2. 
And, that's not a problem for the vector class, it's only because I 
modified my copy a little. OK, nevermind then.

On Sat, 23 Jul 2011 13:23 +0100, sam.hack...@sent.com wrote:
Well, when I type -1**2 into Python, it returns -1. If I run 1**2 
+ -1**2 it returns 0. So, is there a bug in Python then? Running 
2.6.6 on Ubuntu 10.10.
Removing the if statement from get_angle fixed the angle problem for 
me, because of this.

On Sat, 23 Jul 2011 13:56 +0200, DR0ID dr...@bluewin.ch wrote:


Your mistake basically was that you assumed that  -1 ** 2 == -1 
which is not.



Hi again

yes, careful with -1**2 == -(1**2) and (-1)**2 , its not the same (and 
the ** operator precedes the - operator hence the -(1**2) if you type in 
-1**2).


To avoid that, you could use a variable:

a = -1

a**2 == 1

Glad you found out. :)

~DR0ID


Re: [pygame] Pygame 2D vector

2011-07-23 Thread DR0ID

On 23.07.2011 14:23, sam.hack...@sent.com wrote:
Well, when I type -1**2 into Python, it returns -1. If I run 1**2 + 
-1**2 it returns 0. So, is there a bug in Python then? Running 2.6.6 
on Ubuntu 10.10.
Removing the if statement from get_angle fixed the angle problem for 
me, because of this.

On Sat, 23 Jul 2011 13:56 +0200, DR0ID dr...@bluewin.ch wrote:


Your mistake basically was that you assumed that  -1 ** 2 == -1 which 
is not.



Hi again


def  get_angle(self):
if  (self.get_length_sqrd()  ==0):
return  0
return  math.degrees(math.atan2(self.y,self.x))



Well the 0 length check is ok, since a 0 length vector does not really 
have an angle. But I guess you see it now.


~DR0ID


Re: [pygame] Re: SDL 1.3 blit speed

2011-07-23 Thread DR0ID

On 13.07.2011 07:32, Brian Fisher wrote:
One particular technique for scrolling multi-layer backgrounds (that 
don't have parallax or animation anyways) is to have one large surface 
which is big enough to cover the screen, and to treat it as a wrapping 
buffer (so you do 4 blits to the screen from the surface in order to 
get the parts of the buffer as they wrap around the edges - hope that 
makes sense). Then as the background scrolls, you render in the newly 
visible parts into the buffer from your layers (using source clipping 
to get just the newly visible portion rendering on top of the newly 
offscreen part)


It can have dramatic speed improvements compared to redrawing all 
layers every time because when you have a lot of layers with 
transparency, all that transparency gets flattened in the cache. The 
blit to the screen from the buffer is just a copy, it doesn't spend 
time on color-key or alpha blending (this technique is actually great 
for when you want alpha blended layers, btw, which can look better 
than color key).  Also, you'll have fewer blit calls as well, which 
means fewer native code crossings from python which are moderately slow.





Hi

Out of curiosity, I have implemented a scrolling buffer (see attachment, 
bottom left is the 'screen', bottom right the 'buffer' and the yellow 
rect is the camera and the background is the 'world').


I encountered some pitfalls:

   * wrapping isn't that easy (need to detect wrapping and fill the
 buffer accordingly)
   * scrolling diagonally can be decomposed into scrolling in each
 axis, but need to use the old values for the first axis you update
 (e.g. I updated the x-axis first, but needed to use the old ypos
 of the camera not the new one)
   * if the scrolling is more than the width or height of the buffer
 then you should refill the entire buffer
   * direction of scrolling changes the positions of the areas that
 need to be updated
   * need of an interface to the world to get the rendered portions
 into the buffer


Therefore I divided the problem in cases:

  1. no scroll (buffer stays as it is)
  2. scrolling without wrapping
  3. wrapping
  4. scrolling distance is grater than either the height or width of
 the buffer (need to refill entire buffer)

The implementation is more a prototype or a proof of concept and is not 
optimized. Also the draw operations are not separated from the update of 
the buffer internals (is there an elegant way to do that?).


If someone has a another (different/better/simpler/faster) way to 
implement such a scrolling buffer, I would definitively be interested to 
see that implementation.


Especially the interface to the world would be interesting. Any 
suggestions are welcome.


As pointed out, this type of scrolling buffer works only with static 
layers. I'm not completely sure of its benefit since you need to blit 
the 4 parts (~ equals 1 full screen blit) to screen each frame. The 
rendering of the world would need to be very expensive to get most 
benefit from it.


Maybe a simpler solution using a buffer that is a bit bigger as the 
screen and use the scroll method of the Surface class and then refilling 
the scroll delta might be faster, but I have neither tested nor profiled 
it (nor do I have an implementation for that idea). You still need to 
blit the entire screen and I'm not sure how the scroll method is 
implemented (since actually one could do a blit on the same surface, but 
this would mean that you do two fill screen blits each frame).


Any suggestions welcome.

Thanks.

~DR0ID
# -*- coding: utf-8 -*-


Scroll buffer prototypes.



import sys

import pygame

# #  


# class ScrollBuffer1D(object):

# def __init__(self, width, height):
# self._buffer = pygame.Surface((width, height))
# self._post_x = sys.maxint
# self._post_y = sys.maxint
# self._cam = pygame.Rect(sys.maxint, sys.maxint, width, height)

# def scroll_to(self, xpos, ypos, world):
# dx = xpos - self._cam.left
# if dx  0:
# if dx  self._cam.width:
# self._refill(xpos, ypos, world)
# else:
# area = pygame.Rect(self._cam.right, ypos, dx, 
self._cam.height)
# surf = world.get_render(area)
# self._buffer.blit(surf, (self._post_x, 0))
# # this would require to clip the subsurface rect to the 
buffer surface size
# # 
world.draw(self._buffer.subsurface(pygame.Rect(self._post_x, 0, dx, 
self._cam.height)), area)
# self._post_x += dx
# if self._post_x  self._cam.width:
# self._post_x -= self._cam.width
# self._buffer.blit(surf, (self._post_x - dx, 0))
# elif dx  0:
# if dx  -self._cam.width:
# self._refill(xpos, ypos, world)
# else:

Re: [pygame] trajectory

2011-07-23 Thread Nathan BIAGINI
Ok so thanks all for all your replies i will work with all that. I don't
know already if i want to use homing missile style which seems to be easier
to code or to use an algorithm to fire straight to the right spot.
To be honest, i'm not native english speaker and it's not always easy to
figure out what you really mean but i'm doing my best.

I just want to ask you Joe about your algorithm :

If you want to have the bullet go straight to the right spot, you need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


Ok so i think the first step is pretty clear to me, the step 2 too but i
don't understand the step 3. My english isn't the best i repeat so... i have
to calculate how long the bullet will take to go to 'newposition'. So i will
get a new time value and then i need to recalculate newposition based on
this new time? And fire at 'newposition'? And also, to be sure,
'newposition' is the virtual position of the target after the time taken by
the bullet to hit it, right?

Sorry if it seems to be straigh forward to you :-)

Of course i will try others way like Lee suggested me.

Thanks.

2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and use that
 vector to translate a bullet each tick, the bullets might miss the enemy.
 Think about it this way, the bullet moves 2 steps toward the enemy, then the
 enemy moves 1 step, then the bullet moves 2, etc.  Because the enemy moves
 the bullet will have to change its direction through the flight.  So you
 could calculate the direction vector between the bullet and the enemy every
 tick and have the bullet move that direction.  That would make the bullets
 kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition converges.
 Practically, iterating once probably gets you close enough unless the
 movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 Hi everyone,

 i would like to know what are the common way to handle trajectory in a
 2d game. In fact, i think of writing a tower defense game and i wonder how
 to handle the trajectory of the missile launch by the towers. I though of
 getting the pos of the tower and the target and create a vector between this
 two entitites to make a sprite translation of this vector but there is maybe
 some tricky stuff to do it.

 Thanks in advance and happy game making all :-)





Re: [pygame] trajectory

2011-07-23 Thread Nathan BIAGINI
Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it will
works in case of re


Re: [pygame] trajectory

2011-07-23 Thread Nathan BIAGINI
Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it will
works in case of really simple tower defense graph, where the target always
progress to a point A to a point B?

2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes.

 So to be more explicit:

 1 Calculate the distance between the source and the target.
 2 Calculate the time for the bullet to move that distance (i.e. by dividing
 this distance by the bullet velocity)
 3 Calculate newposition (multiply the target velocity by the time
 calculated in the previous step, add to original target position)
 1a Recalculate the distance between the source and newposition
 2a Recalculate the time for the bullet to move from the source to
 newposition (i.e. divide the new distance by the bullet velocity)
 3a Recalculate newposition using this new time (multiply the target
 velocity by the new time calculated in the previous step, add to original
 target position)




 On Sat, Jul 23, 2011 at 12:55 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 Ok so thanks all for all your replies i will work with all that. I don't
 know already if i want to use homing missile style which seems to be easier
 to code or to use an algorithm to fire straight to the right spot.
 To be honest, i'm not native english speaker and it's not always easy to
 figure out what you really mean but i'm doing my best.

 I just want to ask you Joe about your algorithm :


  If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


 Ok so i think the first step is pretty clear to me, the step 2 too but i
 don't understand the step 3. My english isn't the best i repeat so... i have
 to calculate how long the bullet will take to go to 'newposition'. So i will
 get a new time value and then i need to recalculate newposition based on
 this new time? And fire at 'newposition'? And also, to be sure,
 'newposition' is the virtual position of the target after the time taken by
 the bullet to hit it, right?

 Sorry if it seems to be straigh forward to you :-)

 Of course i will try others way like Lee suggested me.

 Thanks.

 2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and use
 that vector to translate a bullet each tick, the bullets might miss the
 enemy.  Think about it this way, the bullet moves 2 steps toward the enemy,
 then the enemy moves 1 step, then the bullet moves 2, etc.  Because the
 enemy moves the bullet will have to change its direction through the
 flight.  So you could calculate the direction vector between the bullet and
 the enemy every tick and have the bullet move that direction.  That would
 make the bullets kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition
 converges.  Practically, iterating once probably gets you close enough
 unless the movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI 
 nathan.o...@gmail.comwrote:

 Hi everyone,

 i would like to know what are the common way to handle trajectory in a
 2d game. In fact, i think of writing a tower defense game and i wonder how
 to handle the trajectory of the missile launch by the towers. I though of
 getting the pos of the tower and the target and create a vector between 
 this
 two entitites to make a sprite translation of this vector but there is 
 maybe
 some tricky stuff to do it.

 Thanks in advance and happy game making all :-)







Re: [pygame] trajectory

2011-07-23 Thread Joe Ranalli
Yes, it will work as long as the target doesn't change direction.

On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it will
 works in case of really simple tower defense graph, where the target always
 progress to a point A to a point B?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes.

 So to be more explicit:

 1 Calculate the distance between the source and the target.
 2 Calculate the time for the bullet to move that distance (i.e. by
 dividing this distance by the bullet velocity)
 3 Calculate newposition (multiply the target velocity by the time
 calculated in the previous step, add to original target position)
 1a Recalculate the distance between the source and newposition
 2a Recalculate the time for the bullet to move from the source to
 newposition (i.e. divide the new distance by the bullet velocity)
 3a Recalculate newposition using this new time (multiply the target
 velocity by the new time calculated in the previous step, add to original
 target position)




 On Sat, Jul 23, 2011 at 12:55 PM, Nathan BIAGINI 
 nathan.o...@gmail.comwrote:

 Ok so thanks all for all your replies i will work with all that. I don't
 know already if i want to use homing missile style which seems to be easier
 to code or to use an algorithm to fire straight to the right spot.
 To be honest, i'm not native english speaker and it's not always easy to
 figure out what you really mean but i'm doing my best.

 I just want to ask you Joe about your algorithm :


  If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


 Ok so i think the first step is pretty clear to me, the step 2 too but i
 don't understand the step 3. My english isn't the best i repeat so... i have
 to calculate how long the bullet will take to go to 'newposition'. So i will
 get a new time value and then i need to recalculate newposition based on
 this new time? And fire at 'newposition'? And also, to be sure,
 'newposition' is the virtual position of the target after the time taken by
 the bullet to hit it, right?

 Sorry if it seems to be straigh forward to you :-)

 Of course i will try others way like Lee suggested me.

 Thanks.

 2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and use
 that vector to translate a bullet each tick, the bullets might miss the
 enemy.  Think about it this way, the bullet moves 2 steps toward the enemy,
 then the enemy moves 1 step, then the bullet moves 2, etc.  Because the
 enemy moves the bullet will have to change its direction through the
 flight.  So you could calculate the direction vector between the bullet and
 the enemy every tick and have the bullet move that direction.  That would
 make the bullets kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition
 converges.  Practically, iterating once probably gets you close enough
 unless the movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI 
 nathan.o...@gmail.comwrote:

 Hi everyone,

 i would like to know what are the common way to handle trajectory in
 a 2d game. In fact, i think of writing a tower defense game and i wonder 
 how
 to handle the trajectory of the missile launch by the towers. I though of
 getting the pos of the tower and the target and create a vector between 
 this
 two entitites to make a sprite translation of this vector but there is 
 maybe
 some tricky stuff to do it.

 Thanks in advance and happy game making all :-)








Re: [pygame] trajectory

2011-07-23 Thread Nathan BIAGINI
So if the source if moving to the left, get in range of a tower and during
the algorithm progress go up or down, it will not work. That's it?

2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes, it will work as long as the target doesn't change direction.


 On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it will
 works in case of really simple tower defense graph, where the target always
 progress to a point A to a point B?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes.

 So to be more explicit:

 1 Calculate the distance between the source and the target.
 2 Calculate the time for the bullet to move that distance (i.e. by
 dividing this distance by the bullet velocity)
 3 Calculate newposition (multiply the target velocity by the time
 calculated in the previous step, add to original target position)
 1a Recalculate the distance between the source and newposition
 2a Recalculate the time for the bullet to move from the source to
 newposition (i.e. divide the new distance by the bullet velocity)
 3a Recalculate newposition using this new time (multiply the target
 velocity by the new time calculated in the previous step, add to original
 target position)




 On Sat, Jul 23, 2011 at 12:55 PM, Nathan BIAGINI 
 nathan.o...@gmail.comwrote:

 Ok so thanks all for all your replies i will work with all that. I don't
 know already if i want to use homing missile style which seems to be easier
 to code or to use an algorithm to fire straight to the right spot.
 To be honest, i'm not native english speaker and it's not always easy to
 figure out what you really mean but i'm doing my best.

 I just want to ask you Joe about your algorithm :


  If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


 Ok so i think the first step is pretty clear to me, the step 2 too but i
 don't understand the step 3. My english isn't the best i repeat so... i 
 have
 to calculate how long the bullet will take to go to 'newposition'. So i 
 will
 get a new time value and then i need to recalculate newposition based on
 this new time? And fire at 'newposition'? And also, to be sure,
 'newposition' is the virtual position of the target after the time taken by
 the bullet to hit it, right?

 Sorry if it seems to be straigh forward to you :-)

 Of course i will try others way like Lee suggested me.

 Thanks.

 2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and use
 that vector to translate a bullet each tick, the bullets might miss the
 enemy.  Think about it this way, the bullet moves 2 steps toward the 
 enemy,
 then the enemy moves 1 step, then the bullet moves 2, etc.  Because the
 enemy moves the bullet will have to change its direction through the
 flight.  So you could calculate the direction vector between the bullet 
 and
 the enemy every tick and have the bullet move that direction.  That would
 make the bullets kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition
 converges.  Practically, iterating once probably gets you close enough
 unless the movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI nathan.o...@gmail.com
  wrote:

 Hi everyone,

 i would like to know what are the common way to handle trajectory in
 a 2d game. In fact, i think of writing a tower defense game and i wonder 
 how
 to handle the trajectory of the missile launch by the towers. I though of
 getting the pos of the tower and the target and create a vector between 
 this
 two entitites to make a sprite translation of this vector but there is 
 maybe
 some tricky stuff to do it.

 Thanks in advance and happy game making all :-)









Re: [pygame] trajectory

2011-07-23 Thread Joe Ranalli
You are aiming the bullet based on where you calculate the target will be
when the bullet gets there.  If the target changes direction, your aim is
wrong.

On Sat, Jul 23, 2011 at 1:24 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 So if the source if moving to the left, get in range of a tower and during
 the algorithm progress go up or down, it will not work. That's it?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes, it will work as long as the target doesn't change direction.


 On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it
 will works in case of really simple tower defense graph, where the target
 always progress to a point A to a point B?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes.

 So to be more explicit:

 1 Calculate the distance between the source and the target.
 2 Calculate the time for the bullet to move that distance (i.e. by
 dividing this distance by the bullet velocity)
 3 Calculate newposition (multiply the target velocity by the time
 calculated in the previous step, add to original target position)
 1a Recalculate the distance between the source and newposition
 2a Recalculate the time for the bullet to move from the source to
 newposition (i.e. divide the new distance by the bullet velocity)
 3a Recalculate newposition using this new time (multiply the target
 velocity by the new time calculated in the previous step, add to original
 target position)




 On Sat, Jul 23, 2011 at 12:55 PM, Nathan BIAGINI nathan.o...@gmail.com
  wrote:

 Ok so thanks all for all your replies i will work with all that. I
 don't know already if i want to use homing missile style which seems to be
 easier to code or to use an algorithm to fire straight to the right spot.
 To be honest, i'm not native english speaker and it's not always easy
 to figure out what you really mean but i'm doing my best.

 I just want to ask you Joe about your algorithm :


  If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


 Ok so i think the first step is pretty clear to me, the step 2 too but
 i don't understand the step 3. My english isn't the best i repeat so... i
 have to calculate how long the bullet will take to go to 'newposition'. 
 So i
 will get a new time value and then i need to recalculate newposition based
 on this new time? And fire at 'newposition'? And also, to be sure,
 'newposition' is the virtual position of the target after the time taken 
 by
 the bullet to hit it, right?

 Sorry if it seems to be straigh forward to you :-)

 Of course i will try others way like Lee suggested me.

 Thanks.

 2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and use
 that vector to translate a bullet each tick, the bullets might miss the
 enemy.  Think about it this way, the bullet moves 2 steps toward the 
 enemy,
 then the enemy moves 1 step, then the bullet moves 2, etc.  Because the
 enemy moves the bullet will have to change its direction through the
 flight.  So you could calculate the direction vector between the bullet 
 and
 the enemy every tick and have the bullet move that direction.  That would
 make the bullets kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you need
 to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition
 converges.  Practically, iterating once probably gets you close enough
 unless the movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI 
 nathan.o...@gmail.com wrote:

 Hi everyone,

 i would like to know what are the common way to handle trajectory
 in a 2d game. In fact, i think of writing a tower defense game and i 
 wonder
 how to handle the trajectory of the missile launch by the towers. I 
 though
 of getting the pos of the tower and the target and create a vector 
 between
 this two entitites to make a sprite translation of this vector but 
 there is
 maybe some tricky stuff to do it.

 Thanks in advance and happy game making all :-)










Re: [pygame] trajectory

2011-07-23 Thread Nathan BIAGINI
Yeah but if you calculate the node of the graph where the target will be
when the bullet get there. Can it works?

2011/7/23 Joe Ranalli jrana...@gmail.com

 You are aiming the bullet based on where you calculate the target will be
 when the bullet gets there.  If the target changes direction, your aim is
 wrong.


 On Sat, Jul 23, 2011 at 1:24 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 So if the source if moving to the left, get in range of a tower and during
 the algorithm progress go up or down, it will not work. That's it?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes, it will work as long as the target doesn't change direction.


 On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI 
 nathan.o...@gmail.comwrote:

 Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it
 will works in case of really simple tower defense graph, where the target
 always progress to a point A to a point B?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes.

 So to be more explicit:

 1 Calculate the distance between the source and the target.
 2 Calculate the time for the bullet to move that distance (i.e. by
 dividing this distance by the bullet velocity)
 3 Calculate newposition (multiply the target velocity by the time
 calculated in the previous step, add to original target position)
 1a Recalculate the distance between the source and newposition
 2a Recalculate the time for the bullet to move from the source to
 newposition (i.e. divide the new distance by the bullet velocity)
 3a Recalculate newposition using this new time (multiply the target
 velocity by the new time calculated in the previous step, add to original
 target position)




 On Sat, Jul 23, 2011 at 12:55 PM, Nathan BIAGINI 
 nathan.o...@gmail.com wrote:

 Ok so thanks all for all your replies i will work with all that. I
 don't know already if i want to use homing missile style which seems to 
 be
 easier to code or to use an algorithm to fire straight to the right spot.
 To be honest, i'm not native english speaker and it's not always easy
 to figure out what you really mean but i'm doing my best.

 I just want to ask you Joe about your algorithm :


  If you want to have the bullet go straight to the right spot, you
 need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


 Ok so i think the first step is pretty clear to me, the step 2 too but
 i don't understand the step 3. My english isn't the best i repeat so... i
 have to calculate how long the bullet will take to go to 'newposition'. 
 So i
 will get a new time value and then i need to recalculate newposition 
 based
 on this new time? And fire at 'newposition'? And also, to be sure,
 'newposition' is the virtual position of the target after the time taken 
 by
 the bullet to hit it, right?

 Sorry if it seems to be straigh forward to you :-)

 Of course i will try others way like Lee suggested me.

 Thanks.

 2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and use
 that vector to translate a bullet each tick, the bullets might miss the
 enemy.  Think about it this way, the bullet moves 2 steps toward the 
 enemy,
 then the enemy moves 1 step, then the bullet moves 2, etc.  Because the
 enemy moves the bullet will have to change its direction through the
 flight.  So you could calculate the direction vector between the bullet 
 and
 the enemy every tick and have the bullet move that direction.  That 
 would
 make the bullets kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you
 need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition
 converges.  Practically, iterating once probably gets you close enough
 unless the movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI 
 nathan.o...@gmail.com wrote:

 Hi everyone,

 i would like to know what are the common way to handle trajectory
 in a 2d game. In fact, i think of writing a tower defense game and i 
 wonder
 how to handle the trajectory of the missile launch by the towers. I 
 though
 of getting the pos of the tower and the target and create a vector 
 between
 this two entitites to make a sprite translation of this vector but 
 there is
 maybe some tricky stuff to do it.

 Thanks in advance and happy game making all :-)











Re: [pygame] trajectory

2011-07-23 Thread Joe Ranalli
Oh, sure.  If you know exactly how the target will move and calculate
newposition based on where the target will be including changes of direction
and everything, then you will be aiming at the right spot.  It still seems
like using the homing bullets would be easier though.

On Sat, Jul 23, 2011 at 1:29 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 Yeah but if you calculate the node of the graph where the target will be
 when the bullet get there. Can it works?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 You are aiming the bullet based on where you calculate the target will be
 when the bullet gets there.  If the target changes direction, your aim is
 wrong.


 On Sat, Jul 23, 2011 at 1:24 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 So if the source if moving to the left, get in range of a tower and
 during the algorithm progress go up or down, it will not work. That's it?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes, it will work as long as the target doesn't change direction.


 On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI 
 nathan.o...@gmail.comwrote:

 Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it
 will works in case of really simple tower defense graph, where the target
 always progress to a point A to a point B?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes.

 So to be more explicit:

 1 Calculate the distance between the source and the target.
 2 Calculate the time for the bullet to move that distance (i.e. by
 dividing this distance by the bullet velocity)
 3 Calculate newposition (multiply the target velocity by the time
 calculated in the previous step, add to original target position)
 1a Recalculate the distance between the source and newposition
 2a Recalculate the time for the bullet to move from the source to
 newposition (i.e. divide the new distance by the bullet velocity)
 3a Recalculate newposition using this new time (multiply the target
 velocity by the new time calculated in the previous step, add to original
 target position)




 On Sat, Jul 23, 2011 at 12:55 PM, Nathan BIAGINI 
 nathan.o...@gmail.com wrote:

 Ok so thanks all for all your replies i will work with all that. I
 don't know already if i want to use homing missile style which seems to 
 be
 easier to code or to use an algorithm to fire straight to the right 
 spot.
 To be honest, i'm not native english speaker and it's not always easy
 to figure out what you really mean but i'm doing my best.

 I just want to ask you Joe about your algorithm :


  If you want to have the bullet go straight to the right spot, you
 need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


 Ok so i think the first step is pretty clear to me, the step 2 too
 but i don't understand the step 3. My english isn't the best i repeat 
 so...
 i have to calculate how long the bullet will take to go to 
 'newposition'. So
 i will get a new time value and then i need to recalculate newposition 
 based
 on this new time? And fire at 'newposition'? And also, to be sure,
 'newposition' is the virtual position of the target after the time 
 taken by
 the bullet to hit it, right?

 Sorry if it seems to be straigh forward to you :-)

 Of course i will try others way like Lee suggested me.

 Thanks.

 2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and
 use that vector to translate a bullet each tick, the bullets might 
 miss the
 enemy.  Think about it this way, the bullet moves 2 steps toward the 
 enemy,
 then the enemy moves 1 step, then the bullet moves 2, etc.  Because the
 enemy moves the bullet will have to change its direction through the
 flight.  So you could calculate the direction vector between the 
 bullet and
 the enemy every tick and have the bullet move that direction.  That 
 would
 make the bullets kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you
 need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition
 converges.  Practically, iterating once probably gets you close enough
 unless the movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI 
 nathan.o...@gmail.com wrote:

 Hi everyone,

 i would like to know what are the common way to handle trajectory
 in a 2d game. In fact, i think of writing a tower defense game and i 
 wonder
 how to handle the trajectory of the missile launch by the towers. I 
 though
 of getting the pos of the tower and the target and create 

Re: [pygame] trajectory

2011-07-23 Thread Nathan BIAGINI
Yeah i also think so... and if the bullet is really faster than the target,
it should not be that much visible.

2011/7/23 Joe Ranalli jrana...@gmail.com

 Oh, sure.  If you know exactly how the target will move and calculate
 newposition based on where the target will be including changes of direction
 and everything, then you will be aiming at the right spot.  It still seems
 like using the homing bullets would be easier though.


 On Sat, Jul 23, 2011 at 1:29 PM, Nathan BIAGINI nathan.o...@gmail.comwrote:

 Yeah but if you calculate the node of the graph where the target will be
 when the bullet get there. Can it works?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 You are aiming the bullet based on where you calculate the target will be
 when the bullet gets there.  If the target changes direction, your aim is
 wrong.


 On Sat, Jul 23, 2011 at 1:24 PM, Nathan BIAGINI 
 nathan.o...@gmail.comwrote:

 So if the source if moving to the left, get in range of a tower and
 during the algorithm progress go up or down, it will not work. That's it?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes, it will work as long as the target doesn't change direction.


 On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI nathan.o...@gmail.com
  wrote:

 Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it
 will works in case of really simple tower defense graph, where the target
 always progress to a point A to a point B?


 2011/7/23 Joe Ranalli jrana...@gmail.com

 Yes.

 So to be more explicit:

 1 Calculate the distance between the source and the target.
 2 Calculate the time for the bullet to move that distance (i.e. by
 dividing this distance by the bullet velocity)
 3 Calculate newposition (multiply the target velocity by the time
 calculated in the previous step, add to original target position)
 1a Recalculate the distance between the source and newposition
 2a Recalculate the time for the bullet to move from the source to
 newposition (i.e. divide the new distance by the bullet velocity)
 3a Recalculate newposition using this new time (multiply the target
 velocity by the new time calculated in the previous step, add to 
 original
 target position)




 On Sat, Jul 23, 2011 at 12:55 PM, Nathan BIAGINI 
 nathan.o...@gmail.com wrote:

 Ok so thanks all for all your replies i will work with all that. I
 don't know already if i want to use homing missile style which seems 
 to be
 easier to code or to use an algorithm to fire straight to the right 
 spot.
 To be honest, i'm not native english speaker and it's not always
 easy to figure out what you really mean but i'm doing my best.

 I just want to ask you Joe about your algorithm :


  If you want to have the bullet go straight to the right spot, you
 need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time


 Ok so i think the first step is pretty clear to me, the step 2 too
 but i don't understand the step 3. My english isn't the best i repeat 
 so...
 i have to calculate how long the bullet will take to go to 
 'newposition'. So
 i will get a new time value and then i need to recalculate newposition 
 based
 on this new time? And fire at 'newposition'? And also, to be sure,
 'newposition' is the virtual position of the target after the time 
 taken by
 the bullet to hit it, right?

 Sorry if it seems to be straigh forward to you :-)

 Of course i will try others way like Lee suggested me.

 Thanks.

 2011/7/20 Joe Ranalli jrana...@gmail.com

 It depends what you're trying to do.

 If you draw the straight line between the tower and the enemy and
 use that vector to translate a bullet each tick, the bullets might 
 miss the
 enemy.  Think about it this way, the bullet moves 2 steps toward the 
 enemy,
 then the enemy moves 1 step, then the bullet moves 2, etc.  Because 
 the
 enemy moves the bullet will have to change its direction through the
 flight.  So you could calculate the direction vector between the 
 bullet and
 the enemy every tick and have the bullet move that direction.  That 
 would
 make the bullets kind of arc to the target.

 If you want to have the bullet go straight to the right spot, you
 need to:
 1) calculate how long the bullet will take to get to the enemy
 2) calculate where the enemy will be at that time (newposition)
 3) calculate how long it will take the bullet to get to newposition
 4) recalculate newposition based on the new time

 Technically you could iterate that repeatedly until newposition
 converges.  Practically, iterating once probably gets you close enough
 unless the movement is extremely complicated.


 On Wed, Jul 20, 2011 at 9:14 AM, Nathan BIAGINI 
 nathan.o...@gmail.com wrote:

 Hi everyone,

 i would like to know what are the common way to handle
 trajectory in a 2d game. In fact, i think of writing a 

Re: [pygame] Pygame 2D vector

2011-07-23 Thread Greg Ewing

sam.hack...@sent.com wrote:

It has a get_angle() function, the first line of this checks if 
length_sqrd() == 0, and then returns the angle as 0. This seems wrong to 
me, if the vector is (1,-1), then length_sqrd (1**2 + -1**2) returns 0,


You're fooling yourself with operator precedence. If you're
typing that into the interactive interpreter, you need to
write it as

1**2 + (-1)**2

which has the value 2.

The code given for get_length_sqrd() is

return self.x**2 + self.y**2

which won't suffer from that problem.

--
Greg


Re: [pygame] Pygame 2D vector

2011-07-23 Thread Greg Ewing

DR0ID wrote:

get_length_sqrd just returns the length of a 
vector which does not depend on the quadrant. Using atan2 might be 
simpler


The get_angle() method *does* use atan2. The length check seems
to be just to avoid an exception if the vector happens to be (0, 0).

--
Greg