04552: ssf2t and clones: flashing garbage during intro

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
04552	Graphics	Minor	Always	Dec 7, 2011, 02:21	Dec 9, 2011, 20:19

Tester	MetalliC	View Status	Public	Platform	MAME (Self-compiled)
Assigned To	hap	Resolution	Fixed	OS	Windows Vista/7 (64-bit)
Status [?]	Resolved			Driver	capcom/cps2.cpp
Version	0.144u2	Fixed in Version	0.144u3	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	04552: ssf2t and clones: flashing garbage during intro
Description	there can be seen some trash onscreen during "flashing" parts of intro, especially at the end. 144u1 is OK. probably that deprecat.h removing in u2 caused regression.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version	0.144u1
Affected Sets / Systems	ssf2t and clones

Attached Files	0001.png (6,065 bytes) Dec 7, 2011, 09:38 Uploaded by MetalliC

No.07948 Layne Tester Dec 7, 2011, 08:53	Are you referring to this? http://www.mametesters.org/view.php?id=1182 If yes it's not a bug.
No.07949 MetalliC Developer Dec 7, 2011, 09:44	No, I am talking about another issue. And as was said - it happens every time, and very clearly seen, just need to wait or throttle until Ryu do a fireball in intro.
No.07950 Fujix Administrator Dec 7, 2011, 10:59	I tested with 0.130 for regression test, it doesn't show the full screen garbage screen.
No.07953 AWJ Developer Dec 7, 2011, 17:24 edited on: Dec 7, 2011, 18:07	The intro isn't the only regression; there are graphic errors during gameplay too. They don't happen all the time (or even all the time on specific stages) but seem to be random... so far I've confirmed them on Cammy's, Chun Li's and Guile's stages. In Cammy's stages, the aurora is sometimes in the wrong place and the wrong priority (covering part of the castle walls). In the other stages, the linescrolling region of the floor jitters when a character jumps.
No.07954 hap Developer Dec 7, 2011, 20:13 edited on: Dec 7, 2011, 20:18	Yes, timing is off now. This means cps2_interrupt will have to be updated (no use for scancount either anymore when scanline is in param). Old timing really starts at scanline 240 with vblank_int_hack, this makes scancount 0 when it's not. In the current implementation, I think changing driver_init to state->m_scancount = 19; will bring the timing back to how it was. edit.. And no, simply doing +19 is not a good fix. :P I added that info for us to realize how bad the implementation of irq timing was/is in cps2.c
No.07956 MetalliC Developer Dec 9, 2011, 20:19	issue was resolved, thanks hap. close it pls