- --
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
|
![]() | ||||
Relationships
There are no relationship linked to this issue. |
Notes
5
![]() No.23034
Osso Moderator
Feb 23, 2025, 06:55
|
Regression commit: https://github.com/mamedev/mame/commit/3d8a6a244f767ea7f5d2bc600baed95ba3b02222 |
---|---|
![]() 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 ;-) |
![]() 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. |
![]() 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. |
![]() No.23045
hap Developer
Feb 24, 2025, 17:38
|
Nevermind, screen.cpp partial updates time travel issue is fixed now. |