- --
Viewing Issue Advanced Details
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 | |||
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
|
| ||||
Relationships
There are no relationship linked to this issue. |
Notes
5
![]() 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. |