Simulate a Joystick with mouse movements

[kindlin]

First, I need to preface this discussion with a large I AM NOT TRYING TO AUTOMATE ANY GAME, in fact, I want to do quite the opposite! Read my next paragraph before you lock this thread.

I've tried playing a few of my old favorite '64 games etc using an emulator on my computer, but it doesn't work nearly as well as I would wish because I can only use 4 directional buttons (instead of the joystick) that are simply "active" and "not active" (depressed or free). Running around a dungeon in Zelda OoT (My favorite game) I have a hard time getting exactly where I want to go, or I literally can't hit something because each tap left and right (or up and down, or both) while trying to aim makes it go right past the thing I actually need to hit; so I need to un target, move a little and try again. Basically, the experience is heavily nerfed, and I feel if I could write a script to implement the joystick using mouse movement, it would be perfect!

I have an idea about how I might implement this idea, but I have a few questions. My main idea was to have a graphical display which would snap the mouse to its center. As you move the mouse around/away from the middle the program would translate that as left, right, up, down, etc. I'm pretty sure I can already do that, so here's the tricky part. Lets say I move the mouse about 30 degrees up off the right horizontal, could it possibly do cos(30)=.866 power right arrow and sin(30)=.5 power up? (power being how far I depress the button, 1 being only that button) Or, could i move the mouse just a little up and have it do just power=.5 up (aka, walk forward, not run).

If I can adjust the amount of power a button gets, that would be perfect. I'm not sure it's possible tho. Assuming I can do this, I also have some ideas/am excited to take requests/ideas for this little project, especially about actual functionality. Let's start with this for now though.

[kindlin]

I've tried googling around for ideas on this partial pressing of a button with no success. So if I can't have it only partially depressed, do you have any thoughts on the following solution? It seems to me that theoretically it might work, but it sounds very CPU heavy, possibly slow and not worth it. Do you think it will work?

Going back to my previous example, lets say that I have my mouse 30 degrees above the right horizontal. I'm not sure that makes super sense you to, so heres a stupid ascii pic:

##########################

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#. . . . . . . . . . . . |. . . . . . . . M . .#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#--------------------------------------#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

#. . . . . . . . . . . . |. . . . . . . . . . . .#

##########################

M is where the mouse is located on my little GUI example. This would mean that to travel in that direction at a speed of '1', you would need .866 'speed' right and .5 'speed' up. Now sinceI can't actually send that request, how about this solution:

The program would take a sampling of your mouses position every X seconds, I think I would default .2 second, or 200 ms, as that would be fairly responsive while still getting the actual direction right, explained next. To jump straight in, for our example, it would need to send the right command for .866 seconds of (.866+.5=)1.366 seconds, and send the up command for .5 out of 1.366 seconds. Reducing this to our 200ms response time, it would send the right command for .866/1.366*200=127ms and the up command for .5/1.366*200=73ms. A theoretical example code, which assumes no latency, for how it can do this for THIS example is as follows:

$Rcount=0
$Ucount=0
$ratio=127/73 ;1.74
 
While $Rcount+$Ucount < 200
    If $Rcount/$Ucount < 1.74 then
        send("{right down}")
        $Rcount+=1
        sleep(1)
        send("{right up}")
    Else
 
        send("{up down}")
        $Ucount+=1
     sleep(1)
        send("{up up}")
    EndIf
 
WEnd

The jist of the code is that it goes back and forth sending either right or left at the correct ratio. My problem with this code is that it assumes instantaneous code reading. I just ran this code and it took 4.336 seconds to run. If I remove the sleep(2) it takes only 2.17 seconds, basically exactly half the time, but still 10x as long as I wanted. So lets divided the while's break point by 10, i get a time taken of .3 seconds. 20 times = .3 seconds = 66 commands/second. 200 times = 2.25 seconds = 89 commands/second.

What all that shows is that the latency depends on many things and is hard to acocunt for. On top of that, the accuracy given by 127/73=1.7397 is better than (20*.866/1.366=12.679 -> 13)/(20*.5/1.366=7.321 -> 7) = 1.85. You'll loose accuracy as you degrade the time.

Could this be helped by using C++ and not autoit; take out the middle man?

Any thoughts would be appreciated. Altho considering I got that code, I kind of want to just try it and see if it even looks right in game, which I doubt. I'll reply again if/when I do this.

[sebgg]

I was thinking about this yesterday a little but never came up with anything nice.

I was going along the lines of getting your proportion of up and right arrow, and then do a number of short clicks per 0.1 of a second or something.

so if it was up 5 and right 3 (10 being maximum) then send up for 5/10 of each 0.1second interval, and right3/10 of the same 0.1 second interval.

but i was thingking this may be cpu heavy and depending on the speed of the clikcs, kind of jittery. but i have no real way of testung