09125: brutforc: HUD graphics on the bottom flicker

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
09125	Graphics	Minor	Always	29 days ago	28 days ago

Tester	mmarino4	View Status	Public	Platform	MAME (Official Binary)
Assigned To	hap	Resolution	Fixed	OS	Windows 10/11 (64-bit)
Status [?]	Resolved			Driver	cinematronics/leland.cpp
Version	0.274	Fixed in Version	0.276GIT	Build	64-bit
		Fixed in Git Commit	56a55eb	Github Pull Request #

Summary	09125: brutforc: HUD graphics on the bottom flicker
Description	The HUD graphics on the bottom of the screen flicker as you play. This did not happen on MAME 0.272 or earlier but starting in 0.273 this happens. It's not a consistent pattern of the flicker but if you watch for a few seconds, you'll see it happen. The screenshots provided were taken a split section apart and you can see the HUD is almost completely missing in the first shot. Though not as noticeable, the player controlled character is also missing in that screenshot.
Steps To Reproduce	Start a game. Watch the HUD on the bottom of the screen.
Additional Information
Github Commit

Flags
Regression Version	0.273
Affected Sets / Systems	brutforc

Attached Files	0027.png (21,983 bytes) 29 days ago Uploaded by mmarino4

No.23034 Osso Moderator 29 days ago	Regression commit: https://github.com/mamedev/mame/commit/3d8a6a244f767ea7f5d2bc600baed95ba3b02222
No.23035 hap Developer 29 days ago edited on: 29 days ago	FIY I think wsf also regressed from it, see the soccer field sometimes flickering black in attract mode. 65.95Hz? That smells like something's not right. edit: PCB notes says so: HSync - 16.8822kHz \ VSync - 65.9459Hz / Yes really.... not a typo ;-)
No.23036 hap Developer 29 days ago edited on: 29 days ago	Setting it to 60Hz 'fixes' it as expected, but here's something weird: Even setting it to 59.9 or 60.1Hz causes glitches. Something in the driver or hardware is very strict with timing and really wants a 60Hz refresh rate.
No.23044 hap Developer 28 days ago edited on: 28 days ago	I looked at it a bit further, in short: this sucks and I don't know how to fix it. It's a MAME scheduler time travel issue. timer 1: reset screen.cpp partial updates timer 2: cpu execution slice If timer 1 is triggered before timer 2, and timer 2 calls screen->update_partial or update_now, its local time is potentially before timer 1's timeout. So for this game, it thinks screen vpos is 255 (of the previous frame), while timer 1 has already started scanline 0. Since last partial scanline was reset to 0, it will update the whole screen. Ideally, timer 1 triggers after timer 2, I don't think screen.cpp has any control over that. It's a global MAME issue. For the leland driver, a workaround is to check for (scanline < 240) before each partial screen update.
No.23045 hap Developer 28 days ago	Nevermind, screen.cpp partial updates time travel issue is fixed now.