00949: outzone: In stage 6 there are two blank box on the background.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
00949	Graphics	Minor	Have not tried	Feb 7, 2008, 10:58	Aug 27, 2010, 19:27

Tester	-Misc Reporters-	View Status	Public	Platform
Assigned To	robiza	Resolution	Fixed	OS
Status [?]	Resolved			Driver	toaplan/toaplan1.cpp
Version	0.111u2	Fixed in Version	0.139u2	Build
		Fixed in Git Commit		Github Pull Request #

Summary	00949: outzone: In stage 6 there are two blank box on the background.
Description	In stage 6 there are two blank box on the background.
Steps To Reproduce
Additional Information	Posted by ArcadeNUT
Github Commit

Flags
Regression Version
Affected Sets / Systems	outzone

Attached Files	outzone0111u2gre.png (22,372 bytes) Feb 14, 2008, 17:43
	outzone.txt (3,246 bytes) Aug 27, 2010, 09:13 [Show Content]
	0007.png (32,526 bytes) Aug 27, 2010, 17:53

No.06588 robiza Developer Aug 25, 2010, 11:20	the black tiles have priority = 0; in truxton and vimana tiles with priority = 0 are invisible
No.06590 Haze Senior Tester Aug 25, 2010, 14:46	maybe there is a register to disable certain priority values? or, there is something else special about those tiles in Truxton / Vimana (out of range, ignored by the hw?) or the mixing is actually just a lot more complex. i did briefly look at toaplan1 before, but I'm not sure what combination of chips it uses for the video. With Toaplan 2 we knew that each VDP mixed and output the backgrounds and sprites internally, but if the hardware is separate on Toaplan 1 it could be trickier. could of course be a real game bug here too, if the programmers were sloppy.
No.06591 Kold666 Developer Aug 25, 2010, 18:39	can you make some sort of mod to the program roms so that stage 6 is played first? In this case I can test the stage on real hw ;)
No.06592 robiza Developer Aug 25, 2010, 21:17	or maybe we can make more complex test with a real hw
No.06593 Haze Senior Tester Aug 26, 2010, 11:13 edited on: Aug 26, 2010, 11:35	I am rather unconvinced by the multi-pass rendering in the driver to be honest, I wonder if a custom single-pass renderer would work better, although it depends on what chips are being used on the board. (anybody have a board photo / components list?)
No.06594 Kold666 Developer Aug 26, 2010, 14:14	There are no PALs, just ttl chips, rams and 2 customs
No.06598 Haze Senior Tester Aug 26, 2010, 15:14	is that the same for all toaplan1 boards? i guess knowing what each custom provides would help.. are they the same? could one be sprites and the other tilemaps? or 2 tilemaps each with sprites in ttl? those are the things i'm wondering right now ;-)
No.06599 AWJ Developer Aug 26, 2010, 16:59	Read The Friendly Source... according to src/mame/video/toaplan1.c, one of the customs handles tilemaps and the other handles sprites. Rally Bike, the oldest game, has a different chip for one of the two customs and has different sprites. Notably Rally Bike has its spriteram mapped directly into the 68K address space; spriteram in the other games, and tilemap ram in all the games, is accessed through address/data ports like a TMS9918.
No.06600 Haze Senior Tester Aug 26, 2010, 17:03 edited on: Aug 26, 2010, 17:07	I tend to blank out most of what's in the source and start from scratch with such things.. although it's possibly correct. Anyway, it's quite similar to toaplan2 in some sense, but the tilemap chip appears capable of displaying more layers, but unlike toaplan2, doesn't have the sprites integrated.
No.06601 Kold666 Developer Aug 26, 2010, 17:05	It seems pretty well documented the videohardware. If someone can program me a modified program rom with some kind of button to skip the levels or start from stage 6 I can see if it happens on real hardware.
No.06602 robiza Developer Aug 26, 2010, 17:21	tilemap_draw(bitmap, cliprect, state->pf4_tilemap, TILEMAP_DRAW_OPAQUE, 0); this draw create a bug in vimana
No.06603 Haze Senior Tester Aug 26, 2010, 17:30 edited on: Aug 26, 2010, 17:34	the whole method of drawing the tilemaps looks like a hack to me. also this is clearly flawed if (state->pf3_tilevram16[2*tile_index+1] & 0x8000) tileinfo->category = 0; else tileinfo->category = (attrib & 0xf000) >> 12; this puts all tiles with the 'disable' bit set into category 0. it also puts all tiles with priority 0 into category 0 that's why you get junk when you draw 'priority 0' because category 0 contains 2 different things. also this multi-pass rendering could potentially introduce priority bugs. I'd say the above btis of code are the root of this bug anyway. Priority 0 should be drawn, tiles with the disable bit set should not be put in the same category as priority 0 tiles! A blank tile should be allocated like CPS1/2 so that the tilemap system can handle it.
No.06605 robiza Developer Aug 26, 2010, 17:49	i think truxton needs the tiles with priority = 0 invisible (for pf2,pf3 e pf4)
No.06606 Haze Senior Tester Aug 26, 2010, 17:58	priority 0 invisible , or disabled bit set? look at the code I pasted, the driver is overloading the meaning of priority (category) 0 which is a bad thing.
No.06607 Haze Senior Tester Aug 26, 2010, 20:12 edited on: Aug 26, 2010, 20:19	ok, looks like the invisible bit isn't set anyway, so even if that code is awful, it doesn't help to fix it here. I guess that code was written because the author had already determined that priority 0 wasn't going to be drawn, so moving tiles with the disable bit set to also be priority 0 made sense at the time, it's 'ugly', but sadly not the cause of the problems here.
No.06608 stephh Developer Aug 27, 2010, 08:21	Kold, I've attached a text file which explains a patched routine that allows you to start from any level (1 to 7). Note that this patched routine only works for 'outzone' as the clones have different addresses. I hope that this helps ...
No.06609 Kold666 Developer Aug 27, 2010, 10:42	Stephh, the file is useful for mame, but I don't know how to patch the eprom files in order to use them on my pcb. Maybe someone else can help?
No.06612 robiza Developer Aug 27, 2010, 14:31	i try to see what i can make for patch the eeproms yet, i think the bug i'snt present in thh real hw
No.06613 Haze Senior Tester Aug 27, 2010, 15:02	I think it might end up being a mixing bug, and we only have to hide priority 0 in truxton because it would be invisible for other reasons (solid layers mixed in higher, rendering it invisible or such)
No.06614 robiza Developer Aug 27, 2010, 17:52	in vimana we need to hide priority 0; elsewhere we have a gfx issue (see the attached file)
No.06616 Haze Senior Tester Aug 27, 2010, 18:12	yes i'm nor arguing that there aren't tiles with a priority of 0 that should be hidden, I'm saying maybe there are other reasons the get hidden on real hardware (maybe some register which controls which are active, or some weirdness in the way the real hardware performs mixing which just causes those tiles to be invisible for other reasons)
No.06618 robiza Developer Aug 27, 2010, 19:27	used a different video update routine like rallybik and demonwld