[Home]History of DCBot

Robo Home | Changes | Preferences | AllPages


Revision 15 . . December 5, 2007 7:41 EST by Skilgannon [rotated battlefield]
Revision 14 . . December 4, 2007 23:59 EST by ABC [speed optimising pays]
Revision 13 . . December 4, 2007 21:24 EST by Skilgannon [all makes sense, thanks =) and suggestion...]
Revision 12 . . December 4, 2007 16:23 EST by ABC [iterative pif]
Revision 11 . . December 4, 2007 16:00 EST by Skilgannon [iterative play-it-forward - i don't get it!]
Revision 10 . . April 18, 2006 19:35 EST by ABC [speed x precision]
  

Difference (from prior major revision) (no other diffs)

Changed: 39c39,41
Yes, but that description is a mix of DCBot's and Shadow's current method. In DCBot I used the "iterative search" to speed up the trig needed to convert the enemy's past position to the position it would be in the current situation. Doing that step by step is slow, like you mentioned. But then I remembered I could just convert my relative position to the enemy once at the beginning and then the play-back of the enemy movement becomes just additions of dx/dy. And the final firing angle conversion is just 1 addition. It's so simple! I don't know how I didn't come up with it earlier. Now that I think of it, I can probably compare squared distances and save a sqrt per step. About the rotated battlefield, I thought about that, but that would reintroduce the trig complexity and would probably end up slower than the original method. -- ABC
Yes, but that description is a mix of DCBot's and Shadow's current method. In DCBot I used the "iterative search" to speed up the trig needed to convert the enemy's past position to the position it would be in the current situation. Doing that step by step is slow, like you mentioned. But then I remembered I could just convert my relative position to the enemy once at the beginning and then the play-back of the enemy movement becomes just additions of dx/dy. And the final firing angle conversion is just 1 addition. It's so simple! I don't know how I didn't come up with it earlier. Now that I think of it, I can probably compare squared distances and save a sqrt per step. About the rotated battlefield, I thought about that, but that would reintroduce the trig complexity and would probably end up slower than the original method. -- ABC

No, no need to introduce trig with a rotated battlefield. You have, instead of your typical if(x < 0 || x > width || y < 0 || y > height) bounds checking, something like if( m*x - y/m + k < 0 || m*x - y/m + k > width || ... I doubt the math is right, but what I'm saying is having a rotated battlefield, instead of translating the point to check a standard battlefield each time. -- Skilgannon

Robo Home | Changes | Preferences | AllPages
Search: