Mouse emulation is broken under Windows 3.x

[vosian]

Hello, I installed the project from aur today and I'm having mouse problems, I've only been able to test windows 3.x so I'm not sure if this would happen otherwise.

if I'm playing windowed the speed on which the cursor moves horizontally and vertically differs vastly, the horizontal movement being much faster, additionally there's an area at the top of the window that can't be reached because the cursor always leaves the window before reaching it.

Additionally, although I don't have mouse acceleration set on my DE (kde plasma on xorg), if I move the mouse slowly across the window, the area I can traverse without the cursor leaving the window is much smaller.

These behaviors are inherited by games launched in win 3.x (tested with the built-in win 3.x games and with a fullscreen that requires win 3.x to run).

The inaccessible areas and difference in vertical and horizontal speeds aren't there when playing fullscreen, however the cursor does move faster than on my system, possibly some linear speed increase due to the difference between emulation resolution and monitor resolution (just a guess), so I have to adjust the dpi of my house to use the software comfortably, I wonder if there's any way to tweak this on the config.

I have SDL 2.0.12 installed, if it matters.

[dreamer]

Mouse emulation in Windows 3.x is somewhat problematic for several reasons - we're aware, but thanks for making this report - now we know, that users actually care about this :)

For now, I recommend several workarounds:

1. Use fullscreen (you mentioned it already, but I wanted to reiterate, as in some cases it's the best solution). For new users, who googled this issue in the future: default shortcut for switching to fullscreen is: Alt+Enter
2. Change default mouse behaviour in .conf file in section sdl:

   capture_mouse = onstart middlerelease
   

   or

   capture_mouse = onclick middlerelease
   

(2) will "lock" the mouse cursor to the emulator window, making it behave the same way as in fullscreen (either on start or with the first click) - you can release it with middle-click or with Ctrl+F10. If games you play depend on middle-click (tell us if you'll find any that does!), then you can replace middlerelease with middlegame.

You can also modify cursor behaviour inside the emulator, e.g. to reduce speed to 90% horizontally and 50% vertically:

sensitivity = 90 50

(although I haven't tested this option myself and I don't know if it works correctly). If you'll end up finding perfect sensitivity for your system - tell us, so we could compare with values that work for other users (maybe a simple workaround can be developed for all).

The exact version of SDL2 does not matter in this case, but what might matter is if you use HiDPI screen / windows scaling provided by DE (!) - I do experience the same problem without HiDPI on HD and FHD displays, but details might be different.

Let's keep this issue open for tracking how successive improvements to mouse emulation affect Windows 3.11.

[dreamer]

Similar problems to Windows 3.x are happening in some games (not all), but even then behaviour under Windows 3.x is "special".

This PR is relevant here: #232 (although it's not directly related to Win3.x; DOSBox-X utilizes additional special mouse driver for Win3.11 to fix the cursor IIRC).

[kcgen]

(Edit: @dreamer , you beat me too it :), must have been typing at roughly the same time)

Thanks @sianhulo. Indeed, some programs apply their own mouse positioning that conflicts with the seamless mouse positioning performed by your host-OS's desktop. For these programs, we need to capture_mouse onstart or onclick, which hands over full control of the mouse to the DOS game.

You can set this in your global dosbox configuration file or just for the specific game that needs it. In the latter case, you could create a custom.conf file inside your game's directory containing just these two lines:

[sdl]
capture_mouse = onstart middlerelease

And then launch your game with: dosbox -userconf -conf custom.conf start.bat
The order of these arguments is important; the first -userconf says "load my general user-configuration (global settings)", followed by -conf means override any prior settings with those in custom.conf. You can daisy-chain as many -conf's together as you like.

For Windows 3.1 games in general, I use this win.conf file:

[sdl]
capture_mouse = onstart middlerelease

[dosbox]
machine = svga_s3
memsize = 16

[render]
aspect = false

[cpu]
core    = dynamic
cputype = pentium_slow
cycles  = fixed 25000

[mixer]
rate = 44100

[midi]
mpu401 = intelligent

[sblaster]
sbtype  = sb16
sbbase  = 220
irq     = 7
dma     = 1
hdma    = 5
sbmixer = true
oplmode = auto
oplemu  = default
oplrate = 44100

[gus]
gus = false

[speaker]
tandy     = off
disney    = false
pcspeaker = false

[dos]
xms = true
ems = false
umb = true

[kcgen]

@dreamer, I recently tried PR#232 with Windows 3.1, and the same positioning offset issues occur (in seamless mode). Last time I tested, DOSBox upstream is similarly affected in seamless mode (autolock = false).

[dreamer]

FYI Through trial-and-error process I discovered, that this setting allows Windows 3.11 to run in 1024x768:

[dosbox]
machine = svga_et4000

This works with official drivers for Tseng Labs ET4000 card, without using hacked drivers that someone posted on Vogons.

(not relevant to mouse behaviour)

[kcgen]

allows Windows 3.11 to run in 1024x768

Awesome! I need to try this :-)

[dreamer]

@kcgen yeah - that's why I sad Windows 3.11 is "special". Later today I'll test various sensitivity settings to see what works with my DEs and displays.

If we'll find a sensitivity setting, that will work for Windows 3.11 across the board for all users, then I would be ok with hacking them in dosbox-staging (to be applied when Windows 3.11 is starting). I wouldn't accept such "fix" for games, but this is special edge-case.

[vosian]

for the sake of testing, I tried sensitivity and it does work, I'm using it along with capture mouse, and it's working fine, although I had to reduce sensitivity a lot more than I was expecting.

[dreamer]

@sianhulo what values worked for you?

[vosian]

30 30, I don't think it's just 30% of the "normal" speed, but I also don't have any way to be sure of this either. So it's just a subjective observation.

[dreamer]

For me it's closer to 85 50 (Gnome 3, display 1366x768, Windows 3.11 in 1024x768), but I still can't match vertical position correctly when using seamless (there's some constant vertical shift applied).

Using capture_mouse = onclick middlerelease is the most convenient out of available options for me.

[kcgen]

@dreamer , that's a great idea if we can reliably detect Windows; is there some unique feature that Microsoft uses universally in Windows (3.0, 3.1, 3.11, and various language ports) different from other protected more applications and games?

In addition to mouse capturing, maybe there are other quality of life setting that are always true (or false) when running Windows? Like always needing XMS, never needing EMS, and defaulting the cputype to Pentium_slow instead of auto (which fixes all of those Int21 errors).

[dreamer]

@kcgen Int21 errors? I don't know anything about Int21 errors - let's create a specific bug report for that.