04406: thndrbld: glitchy colours in certain situations, single step problems, -mt changing visible result / stepping behavior

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
04406	Graphics	Minor	Always	Jul 3, 2011, 12:48	15 days ago

Tester	Haze	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	Open	OS	Windows Vista/7 (64-bit)
Status [?]	Confirmed			Driver	sega/segaxbd.cpp
Version	0.143	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	04406: thndrbld: glitchy colours in certain situations, single step problems, -mt changing visible result / stepping behavior
Description	coin up and start the game when the title screen appears. launch a bomb when still on the helipad. note, it appears to be using MAME default colours instead of the proper ones for the first bomb. if you single step this the behavior is even stranger, you see the bad colours for one frame, then they get corrected, without you having to step another frame. running with -mt fixes this issue when it shouldn't affect the emulation at all!
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	thndrbld

Attached Files	thndrbld.png (7,212 bytes) Jul 3, 2011, 15:47 Uploaded by Tafoid Snap from MAME 0.105, showing the default palette on a shift-pause.

No.07626 Haze Senior Tester Jul 3, 2011, 14:21 edited on: Jul 3, 2011, 14:22	This actually seems to be a rather severe core bug, which is showing through in a handful of drivers. Tempted to upgrade it.
No.07629 Tafoid Administrator Jul 3, 2011, 14:52	If you could, please provide a "what it should look like" reference snap as well as a "how it looks now" snap so everyone can understand what specifically the differences are.
No.07631 Haze Senior Tester Jul 3, 2011, 15:13	snapshots seem to be affected by the problems too...it's rather difficult to provide anything It's very obvious if you see it tho, the explosion appears in ugly multi-colours without -mt, but looks fine with it. single stepping you get the ugly colours for a fraction of a second. it also manifests itself on the briefing screen, you see it appear for a fraction of a second with bad colours unless -mt is used, and exhibits the same issue single stepping.
No.07632 Tafoid Administrator Jul 3, 2011, 15:45 edited on: Jul 3, 2011, 15:48	I guess I'm having a hard time believing this might not be an original issue with the game. I tried an older version (mame 0.105) and the first explosion is full of the default 'rainbow' palette showing before the normal palette on the first explosion only. After that, it doesn't seem to be detectable using subsequent bombs. If anything -mt might be skipping that frame of undefined palette which is why it's not able to be paused to show it and it flashes quickly before stopping on the proper palette. Just throwing it out there.. It may also be that the shift-pause behavior has changed over time, leading to different results.
No.07633 Haze Senior Tester Jul 3, 2011, 16:03 edited on: Jul 3, 2011, 16:14	well no board would ever display the MAME default palette, because it's the MAME default palette. (some games do attempt to due to uninitialized palettes which is sometimes a game bug, but chances are this would just be displayed as solid black/white on the board, one of the credits in the first run of Skull Fang (Japan) attract mode suffers from this, it would be nice to know how that appears on a board in the first loop. That's a completely unrelated issue tho) There is an underlying core bug which causes video/palette updates to be synced completely differently when -mt is used, that much is clear (IIRC there was an older bug report with a similar problem for which a hack was put in the driver rather than fixing the real issue) In this case maybe the 'correct' expectation of the driver is that palette/video are incorrectly synced (which could be a bug in itself) but that doesn't change the fact that -mt shouldn't be 'fixing' this, or the single step problem. This type of variable behavior is toxic if you're trying to do accurate emulation of anything because the output of MAME is depending on factors external to the actual driver.
No.10322 AWJ Developer Feb 22, 2014, 04:30	The single step issue is fixed by r27876. The colors no longer change while MAME is ostensibly paused. Instead, you get the bad colors until you step another frame.
No.10331 Haze Senior Tester Feb 24, 2014, 22:41	yeah, it's consistent now at least, the multithreading was masking the real bug.
No.22536 hap Developer 15 days ago	Is it a BTANB? I don't mean MAME's default palette colors, but the game forgetting to update the colors before the 1st explosion. I think the pens for this explosion are at around 0x200. Even if you do this: PALETTE(config, m_palette, palette_device::BLACK) Then, if you let demo mode run for a few seconds, your 1st explosion colors will still be glitchy.