07745: MAME Gameplay position is offset when Windows taskbar is moved to top of screen

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
07745	Graphics	Minor	Always	Sep 8, 2020, 04:44	Sep 12, 2020, 12:46

Tester	jamesm	View Status	Public	Platform	MAME (Official Binary)
Assigned To	cuavas	Resolution	Fixed	OS	Windows 10 (64-bit)
Status [?]	Resolved			Driver
Version	0.224	Fixed in Version	0.225	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	07745: MAME Gameplay position is offset when Windows taskbar is moved to top of screen
Description	When the Windows 10 taskbar is moved from the bottom of the screen to the top of the screen, Mame renders the screen space incorrectly, offsetting down the hight of the taskbar. This is true when MAME is is in full screen (auto) mode.
Steps To Reproduce	1. Unlock and move the Windows Taskbar from the bottom of the screen, to the top of the screen. 2. Launch Mame 0.224 3. Note the screen and UI is offset vertically. Launch a game and see the offset is carried onto the game screen position.
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems

Attached Files

No.17963 Fujix Administrator Sep 11, 2020, 06:35	No repro for me. Windows 10, windowed MAME, d3d.
No.17964 hap Developer Sep 11, 2020, 08:30 edited on: Sep 11, 2020, 08:37	can confirm with: mame64.exe -video bgfx -nowindow Taskbar is not erased. The bug also happens when taskbar is positioned at the left edge. edit Someone on the chat said it also happens with -video gdi. I tried and can confirm.
No.17967 Fujix Administrator Sep 11, 2020, 19:08	Thanks hap, I confirmed the issue.
No.17970 cuavas Administrator Sep 12, 2020, 12:27	I was the one who added the code to make it avoid placing the window under the taskbar with -window -nomax. Is it somehow incorrectly applying the offset when running fullscreen as well? Perhaps it has something to do with the way bgfx uses a borderless window rather than fullscreen exclusive mode.
No.17971 cuavas Administrator Sep 12, 2020, 12:46	Should be addressed by b1b3b92b4b7ba3e144e00fc62e234b293f646c4c. It didn’t break any other use cases in a quick set of tests.