[Gambas-user] translating planar coordinates relative to point's angle

[Kevin Fishburne]

   On 03/15/2011 11:03 AM, Doriano Blengino wrote:

By adding a fixed value to the orientation of the player, at every 
frame, it will run in circle (speed<>0), or it will rotate on-place 
(speed=0). The radius of the circle will be proportional to 
speed/rotational_step...

   Yes, that is true. How far the right stick is pushed horizontally determines
   how much is added or subtracted to the orientation variable. For debugging
   purposes I'm graphically rotating the player to show the orientation, so I
   know that part is working.

Based on what you said I'm guessing I should be using the second method, 
or is there something deeper I need to know?
  

I think there is nothing more to add... it depends on the real movements 
of the player. When it strafes (never heard this term before - had to 
consult a dictionary :-)) does it actually change its path? Perhaps no, 
so the right joystick implements the movements of the player with polar 
notation, while the left one creates missiles which, in turn, are moving 
objects with a given speed and angle (polar again).

   Sorry for the confusion there. The traditional definition of strafing is
   shooting things but in gaming it means lateral (or any) movement. In my case
   strafing means all movement, whether side-to-side, forward or backward. One
   thing  I'm  trying to avoid is "straferunning", which is where the new
   position  is improperly calculated by treating horizontal and verticle
   movement separately (maybe they used two vectors?). The result is that
   moving diagonally is faster than moving in one direction (x=x+1; y=y+1;
   technique=BAD).
   This article gives some good information about this type of control scheme:
   [1]http://en.wikipedia.org/wiki/Strafing_(gaming)
   I  made  this  GIMP diagram to illustrate the controls relative to our
   discussion. It includes my code for calculating orientation and position:
   [2]http://www.eightvirtues.com/sanctimonia/images/stick_mapping.jpg

Polar and cartesian speeds could be combined too, anyway: in a single
frame you can add "polarspeed*cos(polarangle)" to Xpos,
"polarspeed*sin(polarangle)" to Ypos, then add "horizspeed" to Xpos and
"vertispeed" to Ypos. The result is again a vector with an angle, but
you can play with four variables... but I don't think this would lead to
an easy playable game (but you could use this to simulate the back-kick
of a heavy gun. Suppose the player is moving at 45° with speed 10; then
it fires at 135°. You could calculate back_kick_speedX=-cos(fired_angle)
and back_kick_speedY=-sin(fired_angle); then at every frame you move the
player in the usual manner, then add the components back_kick*, then
reduce the back_kick* components to 50% of before. This should simulate
a back-bump which quickly ceases :-)) ). This is not to insist on
Asteroids game, but it was actually behaving like this: the movement was
really in the x/y plane, with decreasing speeds, and when the fuel was
burned those x/y components were adjusted by sin and cos of the ship
orientation. In fact, it was hard to play... :-)

   That sounds like it's somewhere in the area of where I'm failing. Right now
   I'm doing this:
   worldx = worldx + ((Interface.stick_leftx / 131072) * Cos(Rad(orientation)))
   worldy = worldy + ((Interface.stick_lefty / 131072) * Sin(Rad(orientation)))
   Interface.stick_leftx represents the horizontal speed and ranges from -32767
   to +32767. Interface.stick_lefty represents the vertical speed and has the
   same range. These values are the raw data reported from the gamepad and
   indicate how far the stick is being pushed. Values of zero indicate the
   stick is at rest.
   Just to be clear on what -should- be happening, here's an example.
   Player is facing up (0 degrees): left stick pushed up moves up, pushed down
   moves down, pushed left moves left, pushed right moves right.
   Player is facing right (90 degrees): left stick pushed up moves right,
   pushed down moves left, pushed left moves up, pushed right moves down.
   I'm starting to feel like a real idiot here. Not sure how the part of my
   brain that does math got fried, maybe I need some ritalin. :/ Also I really
   appreciate your help. I read and re-read everything you say, trying to
   understand, and am still actively researching this on the net trying to
   figure  it  out.  I  just  found  this  which  may have some relevance
   ([3]http://s1.zetaboards.com/Game_Maker_Cookbook/topic/861865/1/):
   if keyboard_check(vk_left) //Left Strafe
   {
   x-=lengthdir_x(speed,direction-90)
   y-=lengthdir_y(speed,direction-90)
   }
   if keyboard_check(vk_right) //Right Strafe
   {
   x-=lengthdir_x(speed,direction+90)
   y-=lengthdir_y(speed,direction+90)
   }
   It appears they're offsetting the orientation in their movement calculation
   based on what direction the player is trying to move in. -90 for left and
   +90 for right. Those directions are static though and mine use variable
   values from an analog stick. Maybe I need to calculate twice, once for
   Interface.stick_leftx   (offset   by   90   degrees)   and   once  for
   Interface.stick_lefty (not offset)? Wonder if that will produce the dreaded
   straferunning...
--
Kevin Fishburne
Eight Virtues
www: [4]http://sales.eightvirtues.com
e-mail: [5]sales at ...1887...
phone: (770) 853-6271

References

   1. http://en.wikipedia.org/wiki/Strafing_%28gaming%29
   2. http://www.eightvirtues.com/sanctimonia/images/stick_mapping.jpg
   3. http://s1.zetaboards.com/Game_Maker_Cookbook/topic/861865/1/
   4. http://sales.eightvirtues.com/
   5. mailto:sales at ...1887...