Re: [pygame] Re: SDL 1.3 blit speed
Hi DROID, The pygame.examples.scroll demo shows the Surface.scroll method in action. Scroll shifts the pixels on a surface, so only the new parts have to be blitted on. Lenard Lindstrom On 23/07/11 09:22 AM, DR0ID wrote: [snip] 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
Re: [pygame] Pygame 2D vector
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
Re: [pygame] Pygame 2D vector
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] trajectory
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 > 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 wrote: > >> 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 >> >>> 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 >>> wrote: >>> 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 > Yes, it will work as long as the target doesn't change direction. > > > On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI > 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 >> >>> 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 > 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) calc
Re: [pygame] trajectory
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 wrote: > 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 > >> 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 wrote: >> >>> 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 >>> Yes, it will work as long as the target doesn't change direction. On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI 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 > >> 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 >>> 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 Techn
Re: [pygame] trajectory
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 > 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 wrote: > >> 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 >> >>> Yes, it will work as long as the target doesn't change direction. >>> >>> >>> On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI >>> 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 > 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 >> >>> 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
Re: [pygame] trajectory
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 wrote: > 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 > >> Yes, it will work as long as the target doesn't change direction. >> >> >> On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI 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 >>> 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 >>> > 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 > >> 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
Re: [pygame] trajectory
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 > Yes, it will work as long as the target doesn't change direction. > > > On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI 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 >> >>> 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 >>> 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 > 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 > 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
Yes, it will work as long as the target doesn't change direction. On Sat, Jul 23, 2011 at 1:13 PM, Nathan BIAGINI 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 > >> 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 >> 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 >>> 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 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
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 > 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 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 >> >>> 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 >>> 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
Ok. Yeah it's more explicit, thanks to take time to rewrite it. So it will works in case of re
Re: [pygame] trajectory
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 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 > >> 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 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
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 > 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 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] Re: SDL 1.3 blit speed
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)
Re: [pygame] Pygame 2D vector
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" 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] Pygame 2D vector
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" 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
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" wrote: Your mistake basically was that you assumed that -1 ** 2 == -1 which is not.
Re: [pygame] Pygame 2D vector
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" wrote: Your mistake basically was that you assumed that -1 ** 2 == -1 which is not.
Re: [pygame] Pygame 2D vector
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
[pygame] Pygame 2D vector
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
