02092: spinlbrk and clones: Priorities issues

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
02092	Graphics	Minor	Always	Aug 6, 2008, 12:10	Nov 21, 2008, 16:54

Tester	Kold666	View Status	Public	Platform	MAME (Official Binary)
Assigned To	robiza	Resolution	Fixed	OS	Windows XP/Vista 32-bit
Status [?]	Resolved			Driver	vsystem/aerofgt.cpp
Version	0.126u3	Fixed in Version	0.128u4	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	02092: spinlbrk and clones: Priorities issues
Description	The man with the guns should should stay behind the sand
Steps To Reproduce
Additional Information
Github Commit

Flags	Verified with Original
Regression Version
Affected Sets / Systems	spinlbrk and clones

Attached Files	0000.png (18,912 bytes) Aug 6, 2008, 12:10

No.01974 Haze Senior Tester Aug 6, 2008, 12:33	sprites seem to be being drawn in multiple passes in the driver.. I imagine this is the root of the issues as taking such an approach breaks sprite-sprite priority.
No.01976 Kold666 Developer Aug 6, 2008, 14:38	I remember Reip had some headaches to implement correct priorities in turboforce which use same custom chips
No.01977 Reip Developer Aug 6, 2008, 15:20	I never liked how priorities were fixed and it seems it wasn't 100% right
No.01978 Reip Developer Aug 6, 2008, 15:27 edited on: Aug 6, 2008, 15:27	Anyway the sand is in the 2nd tilemap, it isn't a sprite. So maybe sprite-sprite priorities are right.
No.01982 Haze Senior Tester Aug 6, 2008, 16:02	multi-pass sprite rendering on real hardware is somewhat rare (it wouldn't really be efficient to implement in hardware) although in this case it sounds like it's the sprite-tilemap priority that's wrong too, I wasn't in a position to run MAME and check with the previous note.
No.02773 robiza Developer Oct 11, 2008, 17:26	in the source there're these infos pspikes/turbofrc/aerofgtb write to two addresses which look like control registers for a video generator. Maybe they control the display size/position. aerofgt is different, it writes to consecutive memory addresses and the values it writes don't seem to be related to these ones. 00 01 02 03 04 05 08 09 0a 0b 0c 0d ------------------------------------ pspikes 352x240? 57 63 69 71 1f 00 77 79 7b 7f 1f 00 karatblz 352x240 57 63 69 71 1f 00 77 79 7b 7f 1f 00 turbofrc 352x240 57 63 69 71 1f 00 77 79 7b 7f 1f 00 spinlbrk 352x240 57 68 6f 75 ff 01 77 78 7b 7f ff 00 spinlbrk is very different compared with other games i think some bits handle sprite priorities and sprite-tile priorities if you compare spinlbrk with turbofrc you can see sprites are in reversed order and sprite-tile priorities are inverted a fix is very easy but maybe we can make some test in a real pcb! kold, have you got a pcb? (turbofrc or spinlbrk)
No.03069 Tafoid Administrator Nov 21, 2008, 06:29	If this fixed for 0.128u4 or already fixed?
No.03072 Fujix Administrator Nov 21, 2008, 16:54	The fix has been submitted, will be included in the next release.