Newbie question: how to get smooth mouse movement

[ChristopherDrum]

Hello to the community. I did a search through the virtualization board, and didn't see any posts about this. So, probably this means I'm doing something wrong.

With Previous 4.1 (and whatever version I had before, installed around Nov. 2025), I've found mouse control to feel very odd as I move the mouse a little faster. Very slow movements track precisely, but the faster I move the more the cursor feels like its on ice, or skipping, almost teleporting, by a short distance. It makes for a jerky, hard to visually track mouse cursor.

I assume this has something to do with the "motion speed adjustment" but I have no idea what those numbers mean in relation to mouse movement. I could use advice on setting those values.

[andreas_g]

I tried many times to improve mouse movement but it is still not perfect. I can't fix this without detailed information on mouse data on real hardware.

If slow movement is OK and acceleration is too aggressive you can try setting the exponential adjustment to some value below 1. I use 0.9.

[Rhetorica]

Hi, Chris! Welcome to NeXTcommunity! I'm a big fan of Stone Tools. Awesome to see you here.

The problem is not purely a matter of emulation. Probably the single best help for fixing NeXT mouse acceleration under emulation is GKMouseScaler, which you can get from here. It adds a control panel that you can use to redefine the operating system's mouse acceleration curve. The default ROC is an ascending line; I find a flatter line works better:



A flat horizontal line is also pretty effective. This even improves mouse behavior when emulating white hardware, allowing whatever mouse behavior the host OS is using to shine through without any modification; in VirtualBox I actually use a totally flat line for best results.

FWIW the web version of Previous at infinitemac.org completely overrides the mouse coordinates with host system input values. This is probably very hacky and most likely only works if the addresses used by the OS to store this information are hardcoded in advance, but it's such a huge QoL improvement that @andreas_g should definitely consider implementing it (and the requisite guest OS version sniffing) as an experimental option anyway, even if just for fully-patched NS3.3 and OS4.2.

[ChristopherDrum]

@andreas_g Yes, I saw in the release notes over the years that "improved mouse" was a recurring theme. I do appreciate your efforts toward that end and I'll give your recommendation a shot. Slow is fine with me. Well, you know, within reason. 

@Rhetorica A fan of Stone Tools in the wild?! I'm humbled, thank you. That control panel looks like a great addition, thanks for the tip. A flat line sounds like the curve, or lack thereof, that I'd hope for, personally. I'll get that installed, pronto!

[andreas_g]

FWIW the web version of Previous at infinitemac.org completely overrides the mouse coordinates with host system input values. This is probably very hacky and most likely only works if the addresses used by the OS to store this information are hardcoded in advance, but it's such a huge QoL improvement that @andreas_g should definitely consider implementing it (and the requisite guest OS version sniffing) as an experimental option anyway, even if just for fully-patched NS3.3 and OS4.2.

This sounds very interesting! Can you point me to the code that handles this?

[Rhetorica]

This sounds very interesting! Can you point me to the code that handles this?

The Previous tree for infinitemac.org is here: https://github.com/mihaip/previous/tree/829b8627316985762556720cb0996a4a573cecb7

I'm afraid I don't know the codebase nearly well enough to identify where it is, and my remarks about how it works are purely speculative! Maybe if you do a mass diff against a revision from the same era? Seems like it's from the softfloat branch around a year before you started work on SDL3.

[andreas_g]

I checked the code and it seems to use the original mouse handling. There is no code to input absolute mouse coordinates.

[Rhetorica]

Hmm. OK, alternate theory: perhaps mouse input on Windows + SDL3 is actually not very performant and I was so accustomed to it that seeing SDL2 Previous running on WebAssembly was like black magic to me.

Still, maybe there's a way to do this without disassembling half the operating system. From what I can tell the kernel never actually handles absolute mouse coordinates; that part is left up to some other part of the OS, presumably DPS.

If you were to clone the mouse acceleration function in the emulator, it would be possible to guess how the guest OS believes the cursor has moved, compare it to where the host expects it to be, and to send corrections the next time the mouse device is polled for updates, a bit like how latency compensation code code works in multiplayer games. (Though notably the corrections themselves would have to be adjusted for acceleration—basically we'd need an inverse version of the acceleration function, too.)

Of course, it would ideally be a GPL-friendly clean-room re-implementation of the acceleration function, rewritten from a specification of how it works. The Darwin-0.1 tree on GitHub contains the mouse acceleration code, and I could definitely write up such a spec if you think this seems doable and worth doing.

[ChristopherDrum]

Just to jump in for a moment so that there aren't any wild goose chases. I tried the Infinite Mac NeXT setup and am seeing precisely the same behavior with the mouse. So, I guess this means its more of a NeXT thing and not so much of an emulator thing. I haven't had a chance to work with it all yet, but will try to make some time this weekend to play around with the GKMouseScaler.

[andreas_g]

I just committed an improved mouse configuration dialog and some minor improvements to mouse motion handling. Can anyone having issues with the mouse test the latest code and give me some feedback? The code is in r1789, branch_filesharing (SDL3) and branch_softfloat (SDL2) but not yet in trunk.

Note that the values in the dialog only apply to locked mode (cursor locked to window or in fullscreen). I will improve that later if the code works for people in here.

[Rhetorica]

@andreas_g The SDL2 build failed for me because of missing support for nanosleep at sdlhost.c:121:23. I haven't tried making an SDL2 build in a while, so it's not too surprising this flew under the radar. I've updated my build scripts to let me select a branch at checkout so this will be easier to keep up to date in the future, should that be desired.

Windows has its own (deranged, overly complex) method of implementing tiny delays using media timers. Here is a polyfill for MSVC. The SDL3 build (branch-filesharing) works as expected... (once I uninstalled GKMouseScaler, anyway.)

As for performance... due to rounding and precision loss, there is some very strange behavior when moving the mouse at slow speeds. Drawing a circle is hardly possible: it clamps to following straight X or Y lines. Speeding up helps somewhat:



(top left: moving mouse slowly, bottom right: moving mouse faster.)


left: spiral drawn in Draw.app, Previous filesharing r1789, with slowest possible cursor settings
right: spiral drawn in Microsoft Paint, Windows 10, with same raw mouse input DPI on host

Quality is highly dependent on guest system workload. Mouse behavior on my heavily customized OS4.2 install is a fair bit worse than the same on a virgin NS3.3; in particular, even when drawing tight circles very slowly, the cursor sometimes jumps around 15-20 px diagonally instead of sticking to its vertical and horizontal troughs.

In general I'd say this is an improvement. infinitemac is still a lot better for me in terms of performance than MinGW64+SDL3, probably because it is able to maintain a much higher framerate. I am sure the Mac builds are also a great deal more optimized than the ones produced by my toolchain.

[andreas_g]

First on the compilation issue:
Does it help to replace this part in sdlhost.c

Code Select Expand

#if HAVE_NANOSLEEP
#include <errno.h>
#ifdef __MINGW32__
#include <unistd.h>
#else
#include <sys/time.h>
#endif
#endif
#include "host.h"
with this one

Code Select Expand

#if HAVE_NANOSLEEP
#include <errno.h>
#include <sys/time.h>
#endif
#include "host.h"?

Why did you have to uninstall GKMouseScaler? Did it stop working properly with the latest changes?

Do you think there should be a setting to make the cursor even slower in the guest system or are the issues caused by other things than excessive speed?

[Rhetorica]

@andreas_g: The patch above worked to produce a functioning SDL2 build, but the resulting binary is getting very bad performance; moving the mouse around causes performance to dip from 40 MHz down to 30±3 MHz. Oddly, dragging a window causes the speed to shoot up to 60 MHz — naïvely, I assume this is because of the absence of nanosleep. The mouse in this SDL2 build moves very slowly no matter how much I thrash the cursor around, and regardless of what I set the locked mouse speeds to.

I removed GKMouseScaler because my configuration with it was meant to eliminate mouse acceleration and I wanted to make sure I was not encountering any artifacts caused by it interacting with any changes you may have made to mouse motion handling. However that VM was still very slow, so I abandoned that install entirely for testing purposes and switched to a version of NS3.3 that had never had anything like it installed.

[andreas_g]

So it was just a header issue. Your system has nanosleep, but for some reason the header with its definition was not included with MinGW. I will fix that in the repository later today.

What speed setting are you using for Previous? 40 MHz with variable speed mode or something custom?

Did you lock the cursor to the window for testing? This is all very strange. I will simplify the configuration with one single set of values for both locked and unlocked mode. I will post here as soon as it is in the repository.

[andreas_g]

Does the appended patch improve anything?

mouse_patch1.diff