I had written a Windows script for adding three-finger drag[0] that I use daily, perhaps it could provide some inspiration.
Basically, it is an independent subscriber to RawInput messages that only keeps track of whether or not to send three-finger drag, and posts emulated mouse messages using SendInput. I have a few other scripts that each run as independent userland processes that only monitors their own trigger and nothing else.
Tangentially, my TPMouse[1] script implemented inertia in a framerate-independent way so that it uses very little resource while having perfect simulation stability.
A previous discussion where I explained the analytic derivation for this low-resource exact-solution damped inertia can be seen in [10]
Fun fact: every videogame on Windows is potentially a userspace keylogger if you let it run in the background while, e.g. browsing the web etc.
Basically, any application that uses the Raw Input API can request to receive raw device events even when the application is not running in the foreground, by using the RIDEV_INPUTSINK flag.
The app will then receive every raw device input packet that the hardware sends to the system, replete with timestamps[0] and your mouse position when the event happened[1].
In the case of keyboards it would provide the virtuak-key codes and scancodes[10].
Rawinput is used by modern FPS game like Valorant[11], so if you leave it running in the background it may potentially be able to observe your every single keystroke while you use your browser, enter passwords, etc.
TPMouse, my opensource trackball-emulation script that lets you use the homerow as a trackball for your cursor[100], uses Raw Input with the RIDEV_INPUTSINK option so that it runs entirely in userspace without needing to hook to low level drivers.
It is certainly a double-edged sword -- for open source it's a convenience blessing since what you're running can be inspected directly, but in the case of close-sourced games like Valorant you're relying on your trust of Riot Games's intentions and competence.
With the TPMouse script, I implemented the activation shortcut as [LShift][RShift][C (trackball mode) / G (grid mode) / Q (quit)], which I felt had a nice balance between deliberateness and easy-to-reach (since you are using it with your hands on homerow).
Though because some keyboards have key rollover issues with using both Shifts, [Capslock][<modekey>] is also allowed as an alternative activation shortcut.
if you are only every gonna use critical damping, you can do something like:
function crit_response(dt,pos,vel,rate)
local dissipation = math.exp(-dt*rate)
local disspatePos = pos*dissiptation
local disspateVel = vel*dissiptation
local posCarried = 1 + dt*rate
local velCarried = 1 - dt*rate
local posFromVel = dt
local velFromPos = -dt*rate*rate
local newpos = posCarried*dissipatePos + posFromVel*dissipateVel
local newvel = velFromPos*dissipatePos + velCarried*dissipateVel
return newpos , newvel
end
(intentionally verbose for self-didactic purposes to show how you can actually split the dissipation step into its own loop out from the elastic calculation, meaning that you can use this as a more accurate initial guess in numeric simulations compared to just constant-acceleration approximations)
I can see an argument for wanting to go slightly to one side or the other of the critical factor for aesthetic reasons, but yes. If you want "critically-damped spring behaviour" you don't have to go the long way round to get it.
function sprung_response(t,d,v,k,c,m)
local decay = c/2/m
local omega = math.sqrt(k/m)
local resid = decay*decay-omega*omega
local scale = math.sqrt(math.abs(resid))
local T1,T0 = t , 1
if resid<0 then
T1,T0 = math.sin( scale*t)/scale , math.cos( scale*t)
elseif resid>0 then
T1,T0 = math.sinh(scale*t)/scale , math.cosh(scale*t)
end
local dissipation = math.exp(-decay*t)
local evolved_pos = dissipation*( d*(T0+T1*decay) + v*( T1 ) )
local evolved_vel = dissipation*( d*(-T1*omega^2) + v*(T0-T1*decay) )
return evolved_pos , evolved_vel
end
And the embedded interactive demo in the blog post:
I'm hesitant about reposting as all of my submissions had been inexplicably blocked by HN filters, by the time someone vouches the post it has already been buried.
Have you tried reaching out to dang (hn@ycombinator.com)? One of my submissions was blocked and I reached out to him - he responded a while later to tell me that the domain was blacklisted (it was an article I'd written while working with a some org's PR dept. - but it helped to know why it was getting blocked).
> I'm hesitant about reposting as all of my submissions had been inexplicably blocked by HN filters
Almost exclusively submitting content from the same source might look like spam to the system. I‘d try submitting other interesting things that you come across too and see how that goes in the long term.
The automatic edge-panning of topdown games is a behavior inherited from 90s RTS games that has remained largely unchanged.
While it is sufficient for ball-mouse era casual players, it is actually a detrimental mechanic largely avoided by competitive players and considered a beginner's footgun that causes bad habits to develop.
In this playable proof-of-concept, the camera displacement is changed from the traditional time-dependent panning to a direct position-based panning.
This way, competitive players can leverage their mouse control/muscle memory to move their cursor and their camera as quickly as their skills allows.
AutoIt is also great especially for quickly prototyping GUIs.
I recently built a proof-of-concept for a modernized method of interacting with RTS cameras[0], which unfortunately could not be achieved with frameworks like SDL due to their abstraction obscuring some of the native OS functions needed to create my idea.
Using AutoIt lets me basically just treat it as a minimal-boilerplate sandbox to make DllCalls. This also means that I could directly listen as well as post raw device messages. For example, I implemented an inertia-based cursor script that basically lets you use your homerow vim keys like it's a trackball[1], which I now use everyday whenever I'm not with my ThinkPad.
How does AutoIt compare to AHK? I realize AutoIt is not open-source (free EXE), but besides that what are the key differences? The AutoIt VisualBasic-like language looks easier to learn for those of us who grew up on Microsoft. Can anyone confirm that?
I came across this very interesting bit of history while looking for an image to illustrate my RTS camera control concept[0] as an analogy.
It's interesting how a lot of the wartime "computational drudgery" frequently employ women, the perception of which shifted to becoming a more men-dominated employment after the war.
It would be lovely to hear interesting perspectives from people here on what other tidbits you know of about little-known roles and the social climate during the war, or your insights on how things came to be the way they are during and after the war.
