Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
09125 Graphics Minor Always Feb 23, 2025, 03:50 Feb 24, 2025, 17:38
Tester mmarino4 View Status Public Platform MAME (Official Binary)
Assigned To hap Resolution Fixed OS Windows 10/11 (64-bit)
Status [?] Resolved Driver
Version 0.274 Fixed in Version 0.276 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
png file icon 0027.png (21,983 bytes) Feb 23, 2025, 03:50 Uploaded by mmarino4
mmarino4
Relationships
There are no relationship linked to this issue.
Notes
5
User avatar
No.23034
Osso
Moderator
Feb 23, 2025, 06:55
Regression commit: https://github.com/mamedev/mame/commit/3d8a6a244f767ea7f5d2bc600baed95ba3b02222
User avatar
No.23035
hap
Developer
Feb 23, 2025, 14:20
edited on: Feb 23, 2025, 14:23
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 ;-)
User avatar
No.23036
hap
Developer
Feb 23, 2025, 14:38
edited on: Feb 23, 2025, 14:41
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.
User avatar
No.23044
hap
Developer
Feb 24, 2025, 16:22
edited on: Feb 24, 2025, 16:30
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.
User avatar
No.23045
hap
Developer
Feb 24, 2025, 17:38
Nevermind, screen.cpp partial updates time travel issue is fixed now.