Newbie question: how to get smooth mouse movement

[Rhetorica]

Applying that patch to r1789-softfloat definitely seems to give a more solid basis for comparison. The verdict: movement feels extremely slow and sluggish but is at least smooth so long as the linear speed isn't increased past 2 or so. Looking through the values specified in dlgMouse.c, I'm astonished at how slow all the presets are—these are basically unusable in my environment. Unfortunately, usable linear speeds get very hard to control very quickly because of low time resolution and uneven application of the NeXT mouse acceleration; there's zero consideration for smoothing in their algorithm and it shows. I'm definitely putting GKMouseScaler back in; will report on the results next time.

Clockspeed shown on the emulator's status bar still fluctuates wildly when moving the cursor vs. dragging a window, with similar values to what I mentioned previously.

Is there any way the mouse polling rate can be increased? My native builds of Previous seem to be really struggling with this compared to x86 NEXTSTEP under VirtualBox or infinitemac WASM Previous.

[andreas_g]

The verdict: movement feels extremely slow and sluggish but is at least smooth so long as the linear speed isn't increased past 2 or so. Looking through the values specified in dlgMouse.c, I'm astonished at how slow all the presets are—these are basically unusable in my environment.

This is weird. Can you post your configuration file?

[Rhetorica]

Attached.

[andreas_g]

Thank you. It seems I am not able to improve this. Compared to Previous v4.1 is this now better or worse?

[andreas_g]

Another patch is online. It should fix the issue where the cursor sticked to vertical or horizontal lines (your spiral drawing test).

I am looking for more details on NeXT mice in this discussion.

[Rhetorica]

Another patch is online. It should fix the issue where the cursor sticked to vertical or horizontal lines (your spiral drawing test).

A big improvement! Though I did find that I had to draw very slowly or the acceleration would cause some skipping:

Perhaps I still have some use for GKMouseScaler:



I'm using 1.25 linear and 1.0 exponential in both of the above, r1795-filesharing.

The new 'raw mouse input' option seemed to make the mouse move a bit faster but substantially degraded smoothness so I decided to leave it off.

[Geek.Trauma]

Greetings NeXT Community!

This is a related issue; at least, for me.

I've setup Previous 4.1 on a Late 2013 Mac Pro (aka Trashintosh) running MacOS Sequoia (via OCLP).; and also, a 2019 MacBook Pro 16" running MacOS Tahoe.  Both of them experience the same issue with the mouse not being captured by the Previous emulator window.

On Previous 2.6 the mouse was captured properly by the Previous emulator's window (when using an emulated NeXTDimension card for the desktop GUI).  However, under Previous 4.1 the mouse seems to never be "captured" by the emulated NeXTStep window.

This is quite frustrating since the mouse will leave the emulated desktop window before the mouse cursor reaches the edge of the desktop.

Was the mouse capture behavior by the Previous window changed at some point in the evolution of the code base to provide for a more convenient / fluid experience?  Is there a runtime setting or compile time flag that I can set to re-establish the "capture" behavior of the emulator vis-a-vis the mouse?

Thanks!

Geek

[ptek]

Greetings NeXT Community!

This is a related issue; at least, for me.

I've setup Previous 4.1 on a Late 2013 Mac Pro (aka Trashintosh) running MacOS Sequoia (via OCLP).; and also, a 2019 MacBook Pro 16" running MacOS Tahoe.  Both of them experience the same issue with the mouse not being captured by the Previous emulator window.

On Previous 2.6 the mouse was captured properly by the Previous emulator's window (when using an emulated NeXTDimension card for the desktop GUI).  However, under Previous 4.1 the mouse seems to never be "captured" by the emulated NeXTStep window.

This is quite frustrating since the mouse will leave the emulated desktop window before the mouse cursor reaches the edge of the desktop.

Was the mouse capture behavior by the Previous window changed at some point in the evolution of the code base to provide for a more convenient / fluid experience?  Is there a runtime setting or compile time flag that I can set to re-establish the "capture" behavior of the emulator vis-a-vis the mouse?

Thanks!

Geek

On windows when I hit F12 and bring up the menu I click on the "Mouse" menu. I then tick "Enable auto-locking" but that is on Windows.

[andreas_g]

@Geek.Trauma
Nice to read that Previous still works on the old cylindric Mac Pro. Did you try what pTek recommended? Are there any issues left after enabling auto-locking?

Btw.: If you do not like auto-locking you can also manually lock and unlock the mouse by using the shortcut ctrl-alt-m (an overview on shortcuts is in the Keyboard options dialog).

[andreas_g]

Anyone following this discussion might be interested in Previous v4.2. For details see the announcement in Previous' main thread.

[Geek.Trauma]

Hi Andreas,

I have followed this project's development since the version 0.x days.  I just downloaded the Previous v4.2 binary that you posted for MacOS (Intel and Apple Silicon/aka ARM).

I still get the same behavior that the mouse refuses to lock to the Previous window (on the aforementioned Trashintosh running MacOS Sequoia).

I've never (and still don't) see this behavior with v2.6.  Wondering if it might be something with differences between SDL2 vs SDL3?  Also, suspecting the lack of support for the Metal 3 API with the AMD GCN drivers that the OCLP boot loader crams back into the MacOS kernel's driver stack so that the desktop GUI isn't dog slow.

Geek

[Geek.Trauma]

On windows when I hit F12 and bring up the menu I click on the "Mouse" menu. I then tick "Enable auto-locking" but that is on Windows.

I've tried toggling the 'Enable auto-locking' feature.  I get the same non-locking behavior both ways.

I suspect that it has something to do with the ("technically" speaking) unsupported hardware on which I am running MacOS Sequoia (i.e. a Late 2013 Trashintosh). Maybe something in the SDL implementation and or the older AMD D300/D500/D700 drivers that OCLP restores back into the kernel's dynamically loaded set of drivers.