what happens first?

i think its first move then rotate (my mapping works this way and it looks ok)


T2k

from what I can tell, its the same as what T2K said.

but I also send my data to gdarena in that order, so MAYBE it just does it in whatever order we tell it to do it.

Yes and what about strafing and firing?

thanks

They happen "simultaneously"... I guess it would be like turning and then moving. It's not like a 3D graphics API where translation/rotation is order-dependent..

Khawk: It has to be dependant... you either update the angle first, then move along that angle, or move along the original angle, then update the angle. It''s impossible to do both at the same time, and doing it one way or the other DOES change the final destination point if they both turned, and moved/strafed.

I haven''t done this my self, but couldn''t it be done by modifying his own matrix at the end of the update() functions to apply both movement and rotation at the same time when it is loaded into the Modelview Matrix? Just a guess, I''ve never done that my self, but seems like it could be done that way simaltaniously. Could (and probably am) wrong though.

-J

quote:

---

Original post by Ready4Dis
Khawk: It has to be dependant... you either update the angle first, then move along that angle, or move along the original angle, then update the angle. It''s impossible to do both at the same time, and doing it one way or the other DOES change the final destination point if they both turned, and moved/strafed.

---

Um, not really..

I don''t even understand _how_ this question can come up. Your bot rotates about its vertical axis, and not about some imaginary translated axis.

quote:

---

Original post by Jason2Jason
I haven''t done this my self, but couldn''t it be done by modifying his own matrix at the end of the update() functions to apply both movement and rotation at the same time when it is loaded into the Modelview Matrix? Just a guess, I''ve never done that my self, but seems like it could be done that way simaltaniously. Could (and probably am) wrong though.

-J

---

I think the view of movement is just wrong.. it''s a simple:

x += x*sin(theta);

or something like that. It''s not exceptionally complicated.

i still think this needs clarification, 'cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the red position. if i turn first and move forward later, i end up at the blue position...



[edited by - vogela on August 18, 2003 10:54:07 AM]

quote:

---

Original post by vogela
i still think this needs clarification, 'cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the blue position. if i turn first and move forward later, i end up at the blue position...

---

Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

quote:

---

Original post by Khawk

quote:

---

Original post by vogela
i still think this needs clarification, 'cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the blue position. if i turn first and move forward later, i end up at the blue position...

---

Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

---

Thanks for the info. What about strafing? Is strafing performed before or after forward/backward movement? (I assume that strafing is performed after turning.)

The order of move/strafe doesn't matter unless the bot collide with something, but if the bot does collide the order of move/strafe matters.

[edited by - dalleboy on August 18, 2003 11:38:29 AM]

quote:

---

Original post by Khawk

quote:

---

Original post by vogela
i still think this needs clarification, ''cause i still dont see how this exactly works.



assuming my bot is at the black position. if i move forward and then turn right, i end up at the blue position. if i turn first and move forward later, i end up at the blue position...

---

Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

---

The point is, one HAS to happen before the other...

x += cosf(theta);

... but when is theta updated, before or after you add the value, that was the question. It HAS to be one or the other, it can''t be done at the same exact time, it either:

theta+=turn_angle;
x+= cosf(theta)*speed;

or it does this:
x+= cosf(theta)*speed;
theta+=turn_angle;

Both give DIFFERENT results, I was just wondering which way it happens in the code. The man with the diagram showed it pretty well... The first case (angle updated first) would result in the blue location, while the second case (angle updated after) would result in the red location. I was questioning which order it happens in the update function, not what happens between multiple updates.

quote:

---

Original post by Ready4Dis

quote:

---

Original post by Khawk
Assuming you turn and move in the same Update() cycle.. you end up at the blue position no matter what order you send the commands. If you do these things during different Update() cycles, then sure, order matters (i.e. Update() cycle 1 you move, Update() cycle 5 you turn, etc).

---

The point is, one HAS to happen before the other...

x += cosf(theta);

... but when is theta updated, before or after you add the value, that was the question. It HAS to be one or the other, it can''t be done at the same exact time, it either:

theta+=turn_angle;
x+= cosf(theta)*speed;

or it does this:
x+= cosf(theta)*speed;
theta+=turn_angle;

Both give DIFFERENT results, I was just wondering which way it happens in the code. The man with the diagram showed it pretty well... The first case (angle updated first) would result in the blue location, while the second case (angle updated after) would result in the red location. I was questioning which order it happens in the update function, not what happens between multiple updates.

---

Of course, the way you present it here, I could easily agree that it could work different ways, and I could give an answer. The way it was presented and asked originally, however, is rather vague.

Besides, if you do a turn, why in the hell would it not be calculated before the actual rotation?

We don''t know why it wouldn''t be, but we''d rather be sure before writing our code one way or another (prediction code could be effected by this along with many other things).

So to that point, how do stafing and firing fit in?

You''ve stated so far that it is

Turn
Move

Which makes sense... So I''m assuming strafing also follows turning (as this would also make sense), whether it goes before or after move doesn''t matter, so we can assume...

Turn
Move
Strafe

Hopefully firing happens either completely before or completely after all these steps. I''m going to go with AFTER based on the logic you have seemed to use in creating the arena.

But for satefy sake verification would be nice

quote:

---

Original post by Illumini
We don''t know why it wouldn''t be, but we''d rather be sure before writing our code one way or another (prediction code could be effected by this along with many other things).

So to that point, how do stafing and firing fit in?

You''ve stated so far that it is

Turn
Move

Which makes sense... So I''m assuming strafing also follows turning (as this would also make sense), whether it goes before or after move doesn''t matter, so we can assume...

Turn
Move
Strafe

Hopefully firing happens either completely before or completely after all these steps. I''m going to go with AFTER based on the logic you have seemed to use in creating the arena.

But for satefy sake verification would be nice

---

Strafing does follow turning. Firing is prior to all movement.

Ok, good, now it''s settled . thank you.

Hi,
I guess these comments more or less don''t apply to GDArena anymore since the readme states that you can send only one command each update cycle:

quote:

---

As you send commands to the GDArena, only the first time a command is sent will it be executed. This means that if you send a TurnLeft() command early on in your processing, and then later send a TurnRight() command, only the TurnLeft() command will be processed by the arena during that Update() cycle. These commands are processed for the current Update() cycle only, and do not persist once that cycle is over.

---

Am I right here?

quote:

---

Original post by Epidemi
Hi,
I guess these comments more or less don''t apply to GDArena anymore since the readme states that you can send only one command each update cycle:

quote:

---

As you send commands to the GDArena, only the first time a command is sent will it be executed. This means that if you send a TurnLeft() command early on in your processing, and then later send a TurnRight() command, only the TurnLeft() command will be processed by the arena during that Update() cycle. These commands are processed for the current Update() cycle only, and do not persist once that cycle is over.

---

Am I right here?

---

You can send more than one command per Update() cycle as long as the commands are not related. For instance, you can send a turn command, a speed command, and a fire command in one Update(), but you cannot send two turn commands, a speed command, and two fire commands - well, you can, but the result will be the same as the first case because the arena will ignore the second commands.