JProclaimer
Member
I have a space ship coded to turn and face the mouse position. Physics is on. Works great. However, when the object is moving specifically diagonally and the mouse is positioned perpendicular to the ship's movement, its phy_rotation twitches slightly. I did a lot of playing around with different ways to code it, moving certain lines of code in and out of the Step and End_Step events, and I can reduce it a bit but not completely. I also tried adjusting the angular_dampening, but that had no effect.
Now, the camera is following the spaceship, and that coding is in the spaceship object. I started suspecting that the mouse, because it's not really part of the game, is, in a sense, instantly where it always needs to be relative to the screen, whereas the ship object has to be processed by the game. Because of this delay in processing, the exact angle from the spaceship to the mouse wouldn't always be consistent, causing the ship to rapidly turn slightly either way and creating a twitch effect. So I had the ship object draw the angles, and found that, indeed, while moving at a constant, diagonal speed and with the mouse still, the angle was changing slightly.
My solution was to create a buffer relative to the ship's speed. Basically, if the ship's phy_rotation wasn't perfectly aligned with the mouse but still within the buffer, it wouldn't turn. This solved the twitching issue, but then made for really choppy turning when the angle_difference wasn't drastic.
I'm not the most advanced coder out there, but I'm not quite a baby at GMS2 anymore. I can't imagine there's a way to fix it, but it so or if I'm doing something wrong, by all means. Otherwise, I'm more so looking for a workaround or a different way to code this. I don't think my scripts are necessary, but here they are if anyone wants to take a gander:
Turning the object (doesn't make a difference if in the Step or End_Step):
Updating the camera position (in the End_Step of the spaceship). For simplicity, I tried setting the camera view to gx and gy to bypass all the in-between coding, and it didn't make a difference, so issue doesn't lie here:
Finally, this is my adjusted coding to turn the ship towards the mouse, but with the buffer. Basically, it adjusts the size of the buffer (in degrees) based off the speed of the ship and the distance the mouse is from the ship. You will need to know the trigonometry function of tangents to decipher this (it works fine, I think):
So, to recap, it twitches when {ship moving diagonally + mouse perpendicular to ship's movement}. Moving the mouse closer to the ship makes the twitch worse, farther away isn't as bad (the angle difference gets bigger when the mouse is closer, cuz, trigonometry). Moving scripts between the Step and End_Step events doesn't eliminate the issue.
Now, the camera is following the spaceship, and that coding is in the spaceship object. I started suspecting that the mouse, because it's not really part of the game, is, in a sense, instantly where it always needs to be relative to the screen, whereas the ship object has to be processed by the game. Because of this delay in processing, the exact angle from the spaceship to the mouse wouldn't always be consistent, causing the ship to rapidly turn slightly either way and creating a twitch effect. So I had the ship object draw the angles, and found that, indeed, while moving at a constant, diagonal speed and with the mouse still, the angle was changing slightly.
My solution was to create a buffer relative to the ship's speed. Basically, if the ship's phy_rotation wasn't perfectly aligned with the mouse but still within the buffer, it wouldn't turn. This solved the twitching issue, but then made for really choppy turning when the angle_difference wasn't drastic.
I'm not the most advanced coder out there, but I'm not quite a baby at GMS2 anymore. I can't imagine there's a way to fix it, but it so or if I'm doing something wrong, by all means. Otherwise, I'm more so looking for a workaround or a different way to code this. I don't think my scripts are necessary, but here they are if anyone wants to take a gander:
Turning the object (doesn't make a difference if in the Step or End_Step):
GML:
///@param current_angle
///@param goal_angle
///@param turn_speed
function turn_towards(_a,_g,_s) {
var _ad = angle_difference(_a,_g)
return min(abs(_ad),_s) * sign(-_ad)
}
if (phy_rotation != 360 - goal_dir) {
phy_rotation -= turn_towards(360 - phy_rotation, goal_dir, turn_spd)
}
GML:
var gx = phy_position_x - middlex //middlex is just the offset for the camera
var gy = phy_position_y - middley //middley is just the offset for the camera
if (c_lock = false) {
var pan_dist = point_distance(cx,cy,gx,gy)
if (pan_dist > pan_spd) {
var shift_spd = min(10,pan_dist)//pan_dist * pan_spd
var shift_dir = point_direction(cx,cy,gx,gy)
cx += lengthdir_x(shift_spd,shift_dir) + phy_speed_x
cy += lengthdir_y(shift_spd,shift_dir) + phy_speed_y
}
else {
c_lock = true
cx = gx
cy = gy
}
}
else {
cx = gx
cy = gy
}
camera_set_view_pos(view_camera[0],cx,cy)
GML:
var dif = angle_difference(360 - phy_rotation,goal_dir)
var percent = (90 - angle_difference((360 - phy_rotation) + (90 * sign(dif)), goal_dir)) / 90
var point_offset = percent * darctan(phy_speed / point_distance(x,y,mouse_x,mouse_y))
if (abs(dif) > point_offset) {
phy_rotation -= turn_towards(360 - phy_rotation,goal_dir,turn_spd)
}