03406: trckydoc trckydoca: priority problem

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03406	Graphics	Minor	Always	Aug 25, 2009, 12:07	14 days ago

Tester	Kold666	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows XP (32-bit)
Status [?]	Confirmed			Driver	tecfri/sauro.cpp
Version	0.133u3	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03406: trckydoc trckydoca: priority problem
Description	During the introduction, the escaping monsters go behind the black frame on the pcb. In mame, as you can see from the picture, go over the frame. The is another suble difference between the pcb and the emulated game. Sometimes when there are 3 or 4 sprites on the same scanlines, on the original hardware they start to flicker badly (sometimes they disappear completely). I think mame doesn't implement the sprite limit of this hardware.
Steps To Reproduce
Additional Information
Github Commit

Flags	Verified with Original
Regression Version
Affected Sets / Systems	trckydoc trckydoca

Attached Files	0000.png (5,001 bytes) Aug 25, 2009, 12:07

No.04860 hap Developer Aug 25, 2009, 14:28 edited on: Aug 25, 2009, 14:29	For the sprite limit thing, could you post a short video? Preferably from attract/demo. No rush. =)
No.04861 Kold666 Developer Aug 25, 2009, 16:15 edited on: Aug 25, 2009, 16:15	I have only a mobile to record the videos and the refresh rate is similar to the flickering :( So it isn't noticeable The flickering is not very often seen. In the attract mode is not present. I can always make the flickering appear in the second level when you meet on the same floor the monster which throws the pipes. After 3-4 pipes, parts of his head start flickering.
No.22550 hap Developer 14 days ago edited on: 14 days ago	I looked at it again: I don't see any invisible sprites used at the left edge there (in case they used some kind of trick). All spriteram flag bits are used for something else, so there's no priority flag. Same goes for the tilemap. Maybe a tilemap priority pen thing? I don't think so. Oh, and I almost forgot the easiest possible cause: global sprite x pos. But that looks correct compared to pcb video. I also can't find PCB videos of the titlescreen. There are no other places in the game where it may look that sprites need to be behind tiles.