04393: All sets in cps1.c, toaplan2.c: Strange behavior while single frame stepping

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
04393	Graphics	Minor	Always	Jun 28, 2011, 22:25	Feb 3, 2012, 21:42

Tester	AWJ	View Status	Public	Platform	SDLMAME
Assigned To	aaron	Resolution	Fixed	OS	Linux
Status [?]	Resolved			Driver	toaplan/toaplan2.cpp
Version	0.143	Fixed in Version	0.144u7	Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	04393: All sets in cps1.c, toaplan2.c: Strange behavior while single frame stepping
Description	If you pause and single frame step (shift+pause) while playing any toaplan2.c game, the game exhibits sprite-background desynch and other graphical errors that do not happen when the emulation is running at normal speed. Some games are more severely affected than others--bgaregga is particularly bad.
Steps To Reproduce	1. Run bgaregga and start a game 2. Pause when the first enemy tanks scroll into view 3. Single frame step a few times 4. Notice that all the sprites are moving in fits and starts and not in synch with the background planes or even with each other
Additional Information	Regression is SVN r11464 (emu_timers to object conversion)
Github Commit

Flags
Regression Version	0.141u2
Affected Sets / Systems	All sets in cps1.c, toaplan2.c

Attached Files

No.07952 AWJ Developer Dec 7, 2011, 17:21 edited on: Dec 7, 2011, 17:51	Just noticed that cps1.c (but apparently not cps2.c!) is affected as well. It's obvious in sf2ce, for example: jump up and down to make the screen scroll vertically, pause and single frame step during the vertical scrolling, and you'll see the background sprites judder very noticeably.
No.07955 Haze Senior Tester Dec 7, 2011, 21:08 edited on: Dec 7, 2011, 21:08	there's similar glitchy behavior with drivers all over the shop, and has been for many releases... maybe even in excess of a year. maybe some of it will be cleaned up by the deprecat.h changes, but I've witnessed weird behavior in ms32.c (sometimes sprites will lag, sometimes not.. depending on unknown factors, very obvious in gratia when the sprites/bgs desync sometimes but not others, and the same in toaplan2.c as observed here, but it's far from limited to those drivers) the weird thing about ms32.c at least is there's no special EOF handler or anything like that.
No.08142 AWJ Developer Feb 3, 2012, 17:02	Aaron's retirement of SCREEN_EOF and subsequent fixes seem to have resolved this.