EsportToys

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.

[0] https://github.com/EsportToys/TPMouse

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 posted a much more concise derivation (and implementation, in just 16 lines) on HN a while back but didn't gain much traction:

https://news.ycombinator.com/item?id=35899215

Here are the 16 lines in full:

   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:

https://www.desmos.com/calculator/ynbtai98ns

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.

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.

[0] https://github.com/EsportToys/NaturalEdgePan

[1] https://github.com/EsportToys/TPMouse

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.

[0] https://github.com/EsportToys/NaturalEdgePan#figure-2-this-w...

I posted this yesterday but got blocked by the automated filter, attempting again.

I had also made a post on the gamedev subreddit that spurred a discussion with many interesting counterpoints raised:

https://old.reddit.com/r/gamedev/comments/132g7d5/a_more_nat...

In games like League of Legends, novice players are often derided for poor camera control leaving unnecessary screen real estate for where there is no danger, while obscuring the vision for where the threats are.

I believe that this tendency is a result of the crummy way RTS cameras works, and is an unnecessary segregation point that does not really add to skill expression.

By replacing the fixed-velocity panning with displacement-based panning, not only do the player have full control over how fast or how precise they want to move the camera, it also extends the natural "mouseable zone" from just the small game viewport into whole playable map.

Now the game window is more like the "focus of vision" while your virtual "hand" is no longer constrained to where your "eyes" are looking

I dunno, I find AHK's syntax really hard to wrap my head around, whereas AutoIt is simplistic enough that I never had to even bother with the forums in the first place, the built-in helpfile basically has everything I needed.

Oh, interesting, I wasn’t aware of how the community were, since their documentation is quite thorough and self-contained that I’ve never had the need to check their forums (on top of the language being quite straightforward). I learned entirely from the inline samples provided in every page of their documentation.

I personally use AutoIt a ton as a super fast way to quickly prototype GUIs. It's basically a really simple entrypoint for WinAPI.

Shameless plug: my script for emulating a trackball with your keyboard [0], and my tray app for quickly tweaking your cursor speed (usually for when I'm drawing something)[1]

There are also some really useful utility apps like WhyNotWin11[2] that's made entirely using AutoIt

  [0] https://github.com/EsportToys/TPMouse
  [1] https://github.com/EsportToys/MouseTray
  [2] https://github.com/rcmaehl/WhyNotWin11

Does AutoIt count?

https://github.com/EsportToys/MouseTray

Pretty much all the time, whenever I'm not on my ThinkPad keyboard I use it in place of the trackpoint when I need to make small text selections etc without moving my hands away from the homerow.

Thanks, the TikTok style subtitles are a good idea.

A bit late to the party, but I’ve just released v1.0 of TPMouse, for Windows: https://github.com/EsportToys/TPMouse

Working on a keyboard-based inertial cursor navigation script[0] inspired by rvaiya/warpd[1]. I have just finished the inertia system yesterday but trying to figure out which default key combos to use as to avoid colliding with common OS keybinds in most situations

[0] https://github.com/EsportToys/AutoWarpd/tree/v0.2-inertia

[1] https://news.ycombinator.com/item?id=33222215

It's like AutoHotKey but designed to be more programming- rather than scripting-oriented. It is astonishingly easy to create GUIs in AutoIt in comparison, I use it to rapidly prototype UX ideas.

In fact, historically AHK is actually a fork of AutoIt.

Added rudimentary README to the repo

Ctrl+Win+G to activate, then uijk to move quadrants and m,. for left/middle/right clicks

(followup on previous comment) finished in three hours [2022-10-16-13:00-Z]:

https://github.com/EsportToys/AutoWarpd

Saw this thread just now, I'm gonna try to implement this in AutoIt, let's see how long it takes me! [2022-10-16-09:58-Z]

1)

Basically, for message-based devices like mice, because the RawInput API just simply posts messages to the application's message queue, the events arrive in exactly the order as had been generated by the hardware. All the application needs to do is to process them message-by-message, rather than lumping the result together as a single state.

In the glfw code you linked, you can see that they use `PeekMessage` as a non-blocking way to check for presence of events in the message queue. This is also the case for basically every other frameworks too like SDL2, when what they should be doing instead is have a separate lightweight thread that runs the blocking `GetMessage` counterpart, and the very first line to execute right after `while GetMessage` is to query the high-precision timer to timestamp the exact instant that the OS places the message in the queue.

Frameworks that offer "blocking" versions of their API call don't actually use the blocking call, they just simply skips the game loop until they happened to poll a message, so it is still beholden to the poll timing rather than the OS's unblock timing.

2)

Thanks, I actually found the same link after Googling the tutorial name of the rotted link. I'm actually looking to have Rust as my "main" system programming language.

However, the biggest annoyances for all of the compiled language that I've surveyed is the lack of a "dummy-proof" portable way to set up the toolchain, unlike AutoIt where I can drag the text file to an exe and instantly test it. I really dislike having dependencies installed on my main OS; Docker as a "click and forget" compiler was promising at first but the setup process is still something that I had to look up, which just eventually became too much of a cognitive hassle and ended up reverting to the "easy prototyping" languages whenever I'm doing anything exploratory, which means that I never ended up having those exploratory scenarios being applied on the languages that I needed to familiarize myself with.

Thank you!

1) I think anything that Autoit can DllCall with should be doable though I'd need to really study and play around with how the API works to get a good idea of how it could be integrated or if it is more appropriate as a separate application. It seems that DirectInput is generally deprecated nowadays, Microsoft suggests rawinput for message-based devices like Mice/Keyboard, and XInput or directly querying HID file for state-based devices like Joysticks. It would definitely be interesting to experiment to figure out why older games that used DirectInput have issues such as dropped inputs etc.

2) Thanks for pointing that out! I definitely want to figure out how the least possible latency overhead could be achieved for accurate timestamping of input events. Pretty much all frameworks like SDL2 used by games all seem to use a polling based approach for message retrieval, which makes reliable timestamping impossible. It is due to this flawed polling philosophy that esport games all need framerate far above refresh rate because, despite Windows already providing the machinery to accurately sequence user inputs, commercial game engines just dump all the work into each frame and so you actually lose input-order information within a frame. Particularly notorious is Valorant's clunky aiming despite Riot's self-congratulatory "esport-focused optimization" that mostly just made things worse, like reintroducing floating-point camera jitter because they changed from UE4's default quaternions into successive rotation matrix multiplications.