Then don't remote control play 😉

You'd probably need the SDL2 ported DOSBox for that to work correctly.

SDL2 won't help: the behaviour is exactly the same(tested with Dosbox(and Dosbox-X) using SDL and UniPCemu using SDL and SDL2). All have the exact same problem. So it's a general problem still unfixed in SDL or Windows.

Sooo... take it to SDL.

Strange thing: posted a bug report some time ago about the bug, but nobody's done anything about it.

https://bugzilla.libsdl.org/show_bug.cgi?id=3518

well, that's not strange, it's just how important a bug in this special case is deemed...

It just breaks all SDL games using the mouse and mounting it(e.g. stuff like Doom mouse movement) when using RDP on all Windows 10 PCs? Thus making those games literally unplayable over RDP? Like one little 1mm notch to move the player 180° or more? No proper way to aim anywhere? Windows' under Dosbox (or any other SDL-based x86 emulator) literally unusable mouse(unless you WANT your mouse to always be in one of the four corners of the screen)? Also I don't know if this happens on older versions of Windows as well(XP Pro, Vista Pro, 7 Pro, 8 Pro)? Anyone knows if they have the same problems?

When I try to use mouse input with Dosbox when using Remote Desktop, the mouse movement (relative and absolute) movements are multiplied by a ridiculous amount(also affected by the monitor DPI setting. This makes the mouse movement ridiculous when using RDP(Using a 640x480 game moving the mouse a single mm(minimal mouse movement) moves the emulated mouse to the four corners of the screen(tested with Windows 95 as well as Megarace. Should also be the case with any other applications&games using the mouse, e.g. ms-dos edit.com etc..

UniPCemu uses a very simple fix for this, by dividing the input movement when receiving it when RDP is detected(either through command line parameter(RDP) or registry-based autodetection) when starting the emulator.

This is what UniPCemu uses to normalize it to become valid, non-mounted(mounted=SDL mouse locking(and hiding) in place(which Dosbox exits using ALT-F10 I believe):

1	#ifdef IS_WINDOWS
2				if (RDP) //Needs adjustment?
3				{
4					mouse_xmove += floorf((float)event->motion.xrel*(1.0f/34.0f))*GPU_xDTM; //Move the mouse horizontally!
5					mouse_ymove += floorf((float)event->motion.yrel*(1.0f/60.0f))*GPU_yDTM; //Move the mouse vertically!
6				}
7				else //No adjustment?
8			#endif
9				{
10					mouse_xmove += (float)event->motion.xrel*GPU_xDTM; //Move the mouse horizontally!
11					mouse_ymove += (float)event->motion.yrel*GPU_yDTM; //Move the mouse vertically!
12				}

As you can see, UniPCemu also takes dots to mickeys in account(GPU_[x/y]DTM), since it emulates a mouse that reports in mickeys(mm) instead of pixels.

It would be nice to have something like this in Dosbox, as stuff like games or Windows(any version) without proper mouse movement can be a pain to navigate(especially when being unable to use alt-tab or other windows key combinations due to Windows intercepting them.

As you can see, mouse movement is multiplied by 34(horizontally) times or 60(vertically). This applies to direct input(mouse locked in place) only. Seems to be a SDL bug(any version), I've already reported it a long time ago, but no effect(no response from anyone on said bug)?

Anyone?

One thread about this is enough, so the two have been merged.

Mm, I never noticed the mouse being off in an extreme manner. I have used dosbox a few times over RDP, however that was not with a locked mouse.

What weird numbers.. 34 and 60... 32 and 64 would have made some more sense

If it is on any interest, the same happens with Teamviewer (so it's not only Microsoft's RDP)

Is the issue Ben describes in this thread it? https://social.technet.microsoft.com/Forums/w … winserverhyperv

Attaching the USB mouse to the RDP session seems to work here:

Erratic mouse movement in 3D games over RDP with RemoteFX
https://superuser.com/questions/849918/errati … =google_rich_qa

Looks like citrix supports relative:
https://docs.citrix.com/en-us/receiver/window … -5/improve.html

@DosFreak: Not entirely: The multiplier is a constant value. It doesn't change based on the location of the mouse, as is implied. 100,100=>101,101 reports 34,60. 0,0=>1,1 reports 34,60. 1000,1000=>1001,1001 reports 34,60. Reported movement is always x34 and x60 for the related movement. Of course, absolute location reported does the same(but increase/decrease by that amount).

Currently, the only way I can fix it is dividing x&y reported by 34&60 in relative mouse mode when RDP is detected.