• Hey! Guest! The 40th (!!!) GMC Jam will take place between February 25th, 12:00 UTC to March 1st 12:00 UTC. Why not join in this very special anniversary jam! Click here to find out more!

SOLVED Point Direction Issue

Hey Community! :)

Firstly, here's a video of my problem:

As you can see I have an object that "looks" at the mouse, the hammer. But as I my mouse gets closer to the origin point of the object it seems like the object starts to switch direction each frame.
Here's my code:
GML:
if(mouse_x < x) 
{ 
    image_yscale = -1;
    with(creator) { image_xscale = -1; }
}
else 
{ 
    image_yscale = 1;
    with(creator) { image_xscale = 1; }
}
dir = point_direction(x, y, mouse_x, mouse_y);
direction = dir;
image_angle = direction;
What I guess is maybe the value stored in dir isn't a full integer and thats why it starts switching directions?
Can it be fixed with flooring the variable or something like that?
Why is this issue happening and is there a way to fix it?

Thanks a lot for your help guys! :)
 

Xer0botXer0

Senpai
It gets more sensitive the closer to the point origin, you could add either add a buffer to reduce the turning speed at closer distances, or disable it when the mouse is too close.

How ever I'm sure someone has a better alternative.
 

samspade

Member
The why is pretty straight forward, it is because the value is changing. The 90 degree flip is also pretty straight forward. The closer you are to the origin, the more minor variations will have huge swings. Also, point_direction might return 0 by default (i.e. if x and y equal mouse_x and mouse_y) The real questions is why is the value changing? In theory it shouldn't, all though there are lots of things exist that could do it.

Are you using any of the built in variables such as speed, hspeed, or vspeed? And will it go away if you just directly set image_angle to dir (rather than using direction)? Where is the origin of the sprite?

I might use show_debug_message on dir to see what it is each frame.
 

Mr Magnus

Viking King
Your mouse jitters ever so slightly and the values involved have gotten so small we're dealing with rounding errors.

I'd suggest just having a radius where the hammer simply doesn't follow the mouse but retains the last value, or at least gets a lot less sensitive.
 
The why is pretty straight forward, it is because the value is changing. The 90 degree flip is also pretty straight forward. The closer you are to the origin, the more minor variations will have huge swings. Also, point_direction might return 0 by default (i.e. if x and y equal mouse_x and mouse_y) The real questions is why is the value changing? In theory it shouldn't, all though there are lots of things exist that could do it.

Are you using any of the built in variables such as speed, hspeed, or vspeed? And will it go away if you just directly set image_angle to dir (rather than using direction)? Where is the origin of the sprite?

I might use show_debug_message on dir to see what it is each frame.
I don't use the build-in direction for anything, so I could go away with that, but it doesn't solve the issue.

The origin of the sprite is set like this:
1611266057740.png
 

Mr Magnus

Viking King
Look at Diogenes, your character. He is moving. He shifts slightly up and down as he wields his hammer, and the origin point changes with his jitters. If your mouse is on the origin that small movement is enough for direction to completely change. Either make sure the origin stays exactly put, or make it immune to the mouse being so close to the origin.
 
Last edited:

samspade

Member
I wouldn't use direction as direction, speed, hspeed, and vspeed are all tied together and do things like auto update your x and y. If you only use direction, it probably won't be an issue as the direction won't matter if speed is 0. But @Mr Magnus's seems to be the best overall answer. I didn't actually notice the character move, but that would definitely cause it.
 
Look at Diogenes, your character. He is moving. He shifts slightly up and down as he wields his hammer, and the origin point rotates. If your mouse is on the origin that small movement is enough for direction to completely change. Either make sure the origin stays exactly put, or make it immune to the mouse being so close to the origin.
Ou, actually didn't notice him slightly moving up and down.
Here's the step event of the player object:
GML:
//Collision--------
if(place_meeting(x, y + sign(vertical_movement), obj_collision))
{
    var _obj_collision = instance_place(x, y + sign(vertical_movement), obj_collision);
    y = _obj_collision.bbox_top - 1 - sprite_bbox_bottom;
    vertical_movement = 0;
}
else 
{
    //Gravitation---------
    vertical_movement += gravitation;
}


//Update Position--------
y += vertical_movement;
It has to do something with the collision and positioning on the top of the collision object, but I don't know what's causing it.
 

Mr Magnus

Viking King
Ah, that explains it.

Consider if Player starts on the floor with no vertical movement. This code runs, checks if the player will collide the next time he moves. He will not, so vertical movement gets gravity added on. Y then updates, and the character shifts down a bit.

Next frame: Will the player collide with the floor the next move? Yes, so the player is moved back up and the vertical movement is nulled out. We have now jittered down and up. Repeat every two frames.



I'd suggest that you try this:

GML:
//Gravitation---------
vertical_movement += gravitation;
    
//Collision--------
if(place_meeting(x, y + sign(vertical_movement), obj_collision))
{    //Note that now we will always account for us potentially starting to fall, even if we're still currently. This will ensure the player will not try to move down even if he is currently still.
    var _obj_collision = instance_place(x, y + sign(vertical_movement), obj_collision);
    y = _obj_collision.bbox_top - 1 - sprite_bbox_bottom;
    vertical_movement = 0;
}


//Update Position--------
y += vertical_movement;
 
Top