Jump to content
  • Advertisement
Sign in to follow this  

Mouse direction

This topic is 3602 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm having a lot of trouble deciding how to implement a pretty simple gimmick. I read mouse movement offsets (x,y) per frame, and they can vary when the frame rate is lower or higher. Such as something like -5,2 with a low frame rate, and -1,0 with a high frame rate. What I want to do is find a 2D direction vector, which allows the player to choose what type of attack to launch when an attack button is pressed. So, for example, if the mouse has been moved "mostly" up before the attack button, an upward attack is launched. If it has been moved "mostly" diagonally left-up instead, a different attack is launched. Once I have a direction vector for the mouse, "mostly" becomes an easy dot product operation. My trouble is finding the vector. What would be the best way to do that? 1. Do I record the mouse movement values into offset nodes, one for each frame, and throw away the oldest ones when the total distance reaches a certain value? When the attack is launched, the nodes would all be added together and normalized. 2. Should I record offset nodes per frame, then throw away the oldest ones based on time? Same as above, summed up and normalized on attack. 3. Should I just add each mouse offset, per frame, into a single vector, and average it based on time? 4. Should I add each mouse offset, per frame, into a single vector, and renormalize it each frame? 5. Something else? What I really want to find is the most recent movement vector. But all of these would give me that in different ways. Which do you think would work best for my intended application? I really appreciate any advice.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
if the mouse has been moved "mostly" up before the attack button, an upward attack is launched.


I would change this slightly - When the player wants to fire an attack, he presses a button, moves the mouse in the direction of the attack and releases the button. Then detecting the direction vector is easy - it's just: endPoint - startPoint.

Share this post


Link to post
Share on other sites
Quote:
Original post by Gage64
I would change this slightly - When the player wants to fire an attack, he presses a button, moves the mouse in the direction of the attack and releases the button. Then detecting the direction vector is easy - it's just: endPoint - startPoint.

You could, but you don't have to. Just decide on a time window... say, 0.25 seconds. Record all mouse positions with their timestamps, discarding any older than 0.25 seconds (you can use a deque for this). When you need the velocity, just take the difference of the newest sample and the oldest sample, and divide by the length of the window.

Share this post


Link to post
Share on other sites
So do you think time would make a better offset limiter than mouse movement distance?

An example of what I mean..

Vector record = { 0,10 }; // a member variable

.. in game loop ..

Vector offset = MouseMovementThisFrame;
record.ShrinkLengthBy( offset.Length() );
record += offset;

.. during an attack launch ..

Vector mouse_vector = Normalize( record );

Share this post


Link to post
Share on other sites
I'm not sure what you mean that code to do. What is the exact behavior of ShrinkLenghBy? Do you care what the user's mouse speed is, or only the direction?

Share this post


Link to post
Share on other sites
The idea is to simply delete movement from record, proportional to the length of movement that's being added back in. The farther you move the mouse, the less significant past motions become.

I'm not entirely sure it will work the way I want, though, without testing it.

I only care about the user specifying a direction. But if employing mouse speed makes that more intuitive, I wouldn't be against it.

Share this post


Link to post
Share on other sites
Ah, I see. What you're talking about (kind of) is an "exponentially weighted moving average". It would probably work fine (not quite the way you showed it, but with some small modifications), but it's less flexible for fine-tuning than an explicitly held window of data points.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!