Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07401 Graphics Major Always Aug 25, 2019, 01:35 Aug 25, 2019, 10:35
Tester jkm900 View Status Public Platform MAME (Official Binary)
Assigned To hap Resolution Fixed OS Windows 10 (64-bit)
Status [?] Resolved Driver
Version 0.212 Fixed in Version 0.213 Build 64-bit
Fixed in Git Commit Github Pull Request #
Summary 07401: salamand and clones: Sprite flickers randomly
Description salamand has flickers some sprite randomly now. it's regression related to bubble system updates in nemesis.cpp?
Steps To Reproduce Start salamand
Wait a minute when attract demo scene approaching
Additional Information
Github Commit
Regression Version
Affected Sets / Systems salamand and clones
Attached Files
There are no relationship linked to this issue.
User avatar
Senior Tester
Aug 25, 2019, 07:59
Regression very likely here:

VBLANK TIME for salamander and clones was different if compared with all other games in the driver, so probably the screen raw params are not producing the correct timings or there's something that must be changed in IRQs routines. My guess.
User avatar
Aug 25, 2019, 09:30
It is also the only driver with VIDEO_UPDATE_AFTER_VBLANK, that's a more likely cause. If it gets sprite lag without it, maybe the hw has buffered spriteram.
User avatar
Senior Tester
Aug 25, 2019, 10:06
Commit by Kale is the cause of the bug. I just reverted it in my local source and there's no more flickering on sprites.
Changing the AFTER_VBLANK thing to BEFORE_VBLANK makes the game to run really fast, FPS counter shows around 500% speed throttled.
So surely there's something wrong in main IRQ routine or in the VBLANK one.
User avatar
Aug 25, 2019, 10:16
It works fine here if i remove the video attributes flag. The only new thing I'm seeing is 1-line glitches on the left edge of the screen. But I checked youtube PCB vids of attract mode and it happens there too.
User avatar
Senior Tester
Aug 25, 2019, 10:35
Yup, I can confirm it seems fine here too. I probably made a mistake when I re-compiled nemesis.cpp for the third time to test the AFTER_VBLANK attribute.
Fine it's been resolved.