05981: turbofrc: Sprite priority bugs in some stages

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
05981	Graphics	Minor	Always	Jul 6, 2015, 21:26	Jul 8, 2015, 19:33

Tester	izius	View Status	Public	Platform	MAME (Official Binary)
Assigned To	Mamesick	Resolution	Fixed	OS	Windows XP
Status [?]	Resolved			Driver	vsystem/aerofgt.cpp
Version	0.163	Fixed in Version	0.164	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	05981: turbofrc: Sprite priority bugs in some stages
Description	In stage 3, the monster swimming in the background erases the other sprites as it passes under them. Also, in stage 6, the bullets shot by the ground turrets pass behind the other sprites.
Steps To Reproduce
Additional Information	Probably related to 02060 - same driver and same regression version.
Github Commit

Flags
Regression Version	0.147u3
Affected Sets / Systems	turbofrc

Attached Files	0000.png (24,908 bytes) Jul 6, 2015, 21:26 Uploaded by izius Stage 3
	0001.png (21,373 bytes) Jul 6, 2015, 21:27 Uploaded by izius Stage 6
	turbofrc.zip (512,832 bytes) Jul 7, 2015, 05:34 Uploaded by izius Save states taken in stages 3 and 6
	aerofgt.7z (2,326,896 bytes) Jul 7, 2015, 11:03 Uploaded by Mamesick Tiny MAME with fix

No.11845 Haze Senior Tester Jul 7, 2015, 10:42	not too surprising, the sprites are still being drawn with an ugly multi-pass method which is likely to break sprite-sprite priority. knowing where it's important is of course useful.
No.11846 Mamesick Senior Tester Jul 7, 2015, 11:07 edited on: Jul 7, 2015, 11:08	Looks like I fixed it. It seems some priority values where inverted. It's easy noticeable since the intro, though. Izius, would you please so kind to test the game with the attached MAME which only supports all games in the aerofgt.c driver? Please let me know something also for bug 02060. Thank you so much. Unfortunately I'm not able to open your save states, I receive an "invalid header error"...
No.11847 Haze Senior Tester Jul 7, 2015, 16:14 edited on: Jul 7, 2015, 16:26	fwiw there are (I believe) 2 sprite chips on these boards m_spr_old2->turbofrc_draw_sprites(m_spriteram3+0x200,m_spriteram3.bytes()/2,m_spritepalettebank, bitmap, cliprect, screen.priority(), 0); m_spr_old2->turbofrc_draw_sprites(m_spriteram3+0x200,m_spriteram3.bytes()/2,m_spritepalettebank, bitmap, cliprect, screen.priority(), 1); m_spr_old->turbofrc_draw_sprites(m_spriteram3+0x000,m_spriteram3.bytes()/2,m_spritepalettebank, bitmap, cliprect, screen.priority(), 0); m_spr_old->turbofrc_draw_sprites(m_spriteram3+0x000,m_spriteram3.bytes()/2,m_spritepalettebank, bitmap, cliprect, screen.priority(), 1); however as you can see, we call the sprite draw twice for each chip, which is very likely to be wrong. we should call it once per chip (either rendering to temp bitmaps and thenr manually mixing to the final bitmap, or by using pdrawgfx) The multi-pass is a hack which I left in when I refactored the sprite chips because I didn't want to upset the balance too much, and didn't know of the test cases. it does need revisiting properly. actually it looks like it already was using pdrawgfx, badly, rather than doing it single pass as it should.
No.11848 Mamesick Senior Tester Jul 7, 2015, 16:46	Yes, I noticed the double drawing. I looked at 0.147 source, before your merging of all the per game draw_sprites routines into a global one happend in 0.147u3. The behaviour was similar, were used two values: -1 and 0 (which I assume is a sorf of draw/not draw flag). With your conversion you changed to 0 and 1 but (don't take this as an offensive comment please) you inverted the flag. I mean, that in current code, if compared with old hack, -1 is 0 and 0 is now 1. This causes the bugs reported that are appeared again. Instead, the values have to be inverted in this way: old -1 is now 1 old 0 still remains 0 I hope I'm clear in trying to explain what happened during your merging and creation of a global sprites drawing device.... What I'm asking, because I know I'm not able to rewrite the whole thing and/or remove the hacked pdrawgfx usage, am I allowed commit at least the hacky solution in the right way? I played Turbo Force till the 3rd level bug and here now seems ok.
No.11849 Haze Senior Tester Jul 7, 2015, 16:51 edited on: Jul 7, 2015, 16:52	yeah, if I made a mistake then swap them, my intention was minimal impact with a view to revisiting it later, looks like I failed on the minimal impact part ;-)
No.11853 NekoEd Senior Tester Jul 8, 2015, 00:24	Acknowledging this since there's active developer activity.
No.11854 Mamesick Senior Tester Jul 8, 2015, 05:05	https://github.com/mamedev/mame/pull/251
No.11861 izius Tester Jul 8, 2015, 19:33 edited on: Jul 8, 2015, 19:34	I'm probably a bit late, but I tested the tiny Mame build posted by Mamesick. Priorities are OK, so I can confirm this bug and 02060 are ironed out. Thank you.