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]sa...@eightvirtues.com 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:sa...@eightvirtues.com ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
