Mouse control problem with Remote Desktop Connection (windows) about fluidx3d

[rodionstepanov]

@ProjectPhysX I took mouse_sensitivity = 0.01. It looks like the reaction is getting slower but I still cannot control a view angle properly.

[SLGY]

I'm probably telling you something you already know here but you just turn off mouse-input with the "u" key and alt-tab in/out of the program where required to avoid clicking the app window and re-enabling the mouse. I do a lot of remote desktop stuff to the workstation and just turn down the multipliers for I/J/K/L keys, using the mouse is a write-off on remote sessions for me.

[ProjectPhysX]

Hi @rodionstepanov and @SLGY,

I think the root cause here is that the Windows Remote Desktop client fails to execute the SetCursorPos WinAPI command correctly, so it does not center the cursor after reading the distance between cursor and screen center and you see super fast uncontrollable rotation.

I've written an alternative mouse input method that does not rely on SetCursorPos and should work better on remote systems. Please replace the entire LRESULT CALLBACK WndProc(...) {...} function with this code:

LRESULT CALLBACK WndProc(HWND window, UINT message, WPARAM wParam, LPARAM lParam) {
	if(message==WM_DESTROY) {
		running = false;
		PostQuitMessage(0);
		exit(0);
	} else if(message==WM_MOUSEMOVE) {
		static int last_x=(int)camera.width/2, last_y=(int)camera.height/2;
		const int new_x=(int)LOWORD(lParam), new_y=(int)HIWORD(lParam);
		camera.input_mouse_dragged(new_x-last_x, new_y-last_y);
		last_x = new_x;
		last_y = new_y;
	} else if(message==WM_MOUSEWHEEL) {
		if((short)HIWORD(wParam)>0) camera.input_scroll_up(); else camera.input_scroll_down();
	} else if(message==WM_LBUTTONDOWN||message==WM_MBUTTONDOWN||message==WM_RBUTTONDOWN) {
		ShowCursor(!camera.lockmouse); // show/hide cursor
		camera.input_key('U');
	} else if(message==WM_KEYDOWN) {
		int key = key_windows((int)wParam);
		if(key=='U') ShowCursor(!camera.lockmouse); // show/hide cursor
		camera.set_key_state(key, true);
		key_bindings(key);
	} else if(message==WM_KEYUP) {
		int key = key_windows((int)wParam);
		camera.set_key_state(key, false);
	}
	return DefWindowProc(window, message, wParam, lParam);
}

This workaround is not a suitable general solution however, as rotation stops as soon as the cursor hits the screen boundaries and on small screens you can't fully rotate ±90° vertically and 360° horizontally. So I put this code only here and not in the repo.

As 2 alternatives with the mouse input version in the repo, you can try:

• Disable hiding the cursor, by commenting out all ShowCursor(false); lines in src/graphics.cpp. Apparently hiding the cursor is one of the factors that break SetCursorPos.
• In Windows Group Policy Editor, in Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment, set Use WDDM graphic display driver for Remote Desktop Connections to disable.

Kind regards,
Moritz

[rodionstepanov]

Hi @ProjectPhysX!
Both recipes work but I stay with first one. No issue any more. Thanks a lot. I express my deepest gratitude and respect to you. It is very cool what you are doing.

[ProjectPhysX]

Hi @rodionstepanov,

thanks for reporting this. It's the age-old poor design choice of Microsoft's SetCursorPos itself triggering a WM_MOUSEMOVE event, when setting the cursor back to the center of the screen. Usually in my implementation this is not an issue, as screen_width/2 ad screen_height/2 are subtracted and the resulting movement upon cursor centering is 0/0.

However, in another poor design choice by Microsoft, when the remote screen resolution is different and/or off-set compared to the client screen resolution, SetCursorPos(width/2, height/2) works on client and the reported position from WM_MOUSEMOVE is on remote, and when they mismatch, it adds the off-set mouse movement 60 times a second and rotates the camera very fast.

I have now changed the mouse input routine on Windows to avoid WM_MOUSEMOVE alltogether. Please test this new version on your remote setup and tell me if it resolves the bug!

Kind regards,
Moritz

[rodionstepanov]

I'm sorry but it does not resolve the bug. I've test with setup for 3D Taylor-Green vortices; Looks like sensitivity is very high.

[ProjectPhysX]

@rodionstepanov can you try if reducing the mouse_sensitivity constant helps?