01176: f1dream: [possible] Map display has a wrong priority value. It should cover everything, instead some objects have an higher priority.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
01176	Graphics	Minor	Have not tried	Feb 12, 2008, 09:22	Dec 10, 2009, 14:25

Tester	Kale	View Status	Public	Platform
Assigned To		Resolution	Bugs That Aren't Bugs	OS
Status [?]	Resolved			Driver	capcom/tigeroad.cpp
Version	0.61	Fixed in Version		Build
		Fixed in Git Commit		Github Pull Request #

Summary	01176: f1dream: [possible] Map display has a wrong priority value. It should cover everything, instead some objects have an higher priority.
Description	Map display has a wrong priority value. It should cover everything, instead some objects (tunnels, advertising panels) have an higher priority. Objection from Mamesick in 0.111u2: Are we sure it's not an original game bug? The video hardware is simple, It seems strange that only 1 sprite should be drawn with highest priority...Current priorities order is: background, sprites, foreground. Tiger Road (same driver) don't need at all a different priorities order and don't have any priority bug. Of course, F1dream could have a sort of "special" priority bit for the map, who knows. But Capcom coders were lazy, you know.
Steps To Reproduce
Additional Information
Github Commit

Flags	Possible, Noted in Source
Regression Version
Affected Sets / Systems	f1dream

Attached Files	f1dream061gre2.png (5,007 bytes) Feb 14, 2008, 18:10
Attached Files	f1dream_graphics.jpg (156,113 bytes) Dec 5, 2009, 16:27

No.03509 Kale Developer Jan 6, 2009, 17:31	There's a note at 72-73 of video/tigerroad.c that says "The Track Map should probably be drawn on top of the background tilemap...", and it's possible that there's a sprite bit that controls priority,and it's not an uncommon feature at all...
No.03511 hap Developer Jan 6, 2009, 21:31	Fixed if bit 10 of tile_number is also treated as bg1 priority bit, so: if (tile_number != 0xfff && (tile_number>>10&1)==priority) ... awkward from a hardware point of view though.
No.05239 Stefan Lindberg Senior Tester Dec 5, 2009, 16:28	Added a pic from the PCB. MAME is emulating this graphics behavior perfect ;-)
No.05240 Mamesick Senior Tester Dec 6, 2009, 08:29	Why this bug was re-opened is beyond me. Though we are now sure that MAME behaviour and my objectrions were right.
No.05241 Haze Senior Tester Dec 6, 2009, 14:10	maybe someobdy thought the proposed fix was added, but it wasn't? (I haven't checked) Generally follows the rule tho, if it seems awkward from a hardware sense of view, 99% of the time it's a hack and it's wrong, so it's not really surprising to see the original behavior was correct.
No.05252 Kale Developer Dec 10, 2009, 14:24 edited on: Dec 10, 2009, 14:26	@Mamesick: if you don't have true proofs (original reference, dasm code studying etc.) you can't be 100% sure about it, and since your original argument was based on lateral thinking this report was actually never closed. I've tried to check this at some point but HW didn't seemed to have a per-sprite priority, but still didn't closed the thing, guess why (and no, it's not because I was the original tester, I don't give a crap about it)...now closed as BTANB.