Viewing Issue Advanced Details
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
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
png file icon 0000.png (18,912 bytes) Aug 6, 2008, 12:10
There are no relationship linked to this issue.
User avatar
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.
User avatar
Aug 6, 2008, 14:38
I remember Reip had some headaches to implement correct priorities in turboforce which use same custom chips
User avatar
Aug 6, 2008, 15:20
I never liked how priorities were fixed and it seems it wasn't 100% right
User avatar
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.
User avatar
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.
User avatar
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)
User avatar
Nov 21, 2008, 06:29
If this fixed for 0.128u4 or already fixed?
User avatar
Nov 21, 2008, 16:54
The fix has been submitted, will be included in the next release.