Viewing Issue Advanced Details Jump to Notes ] aerofgt.cpp
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 aerofgt.cpp
Version 0.163 Fixed in Version 0.164 Build Normal
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.
Regression Version 0.147u3
Affected Sets / Systems turbofrc
Attached Files
png file icon 0000.png (24,908 bytes)  Jul 6, 2015, 21:26 by izius
Stage 3
png file icon 0001.png (21,373 bytes)  Jul 6, 2015, 21:27 by izius
Stage 6
zip file icon (512,832 bytes)  Jul 7, 2015, 05:34 by izius
Save states taken in stages 3 and 6
7z file icon aerofgt.7z (2,326,896 bytes)  Jul 7, 2015, 11:03 by Mamesick
Tiny MAME with fix

- Relationships
related to 02060Resolvedrobiza spinlbrk, spinlbrku, spinlbrkj: Priorities wrong in second level 

-  Notes
User avatar
(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.
User avatar
(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"...

User avatar
(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.

User avatar
(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.
User avatar
(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 ;-)

User avatar
(Senior Tester)
Jul 8, 2015, 00:24
Acknowledging this since there's active developer activity.
User avatar
(Senior Tester)
Jul 8, 2015, 05:05
User avatar
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.