00763: vshoot: Some garbage in the left upper corner.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
00763	Graphics	Minor	Have not tried	Feb 4, 2008, 14:23	Dec 27, 2021, 00:35

Tester	qapo	View Status	Public	Platform
Assigned To	Haze	Resolution	Fixed	OS
Status [?]	Resolved			Driver	namco/namconb1.cpp
Version	0.100u2	Fixed in Version	0.237	Build
		Fixed in Git Commit	eca8831	Github Pull Request #

Summary	00763: vshoot: Some garbage in the left upper corner.
Description	vshoot have some garbage in the left upper corner.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	vshoot

Attached Files	vshoot0100u2gre.png (9,479 bytes) Feb 14, 2008, 15:18

No.19601 Osso Moderator Dec 26, 2021, 08:17	No idea of the commit which fixed this.
No.19602 Haze Senior Tester Dec 26, 2021, 12:18 edited on: Dec 26, 2021, 12:25	I disabled the drawing of the secondary list for this driver with one of my commits while working on the sprite device, I'm 99% sure the secondary list is a buffer where data gets copied by DMA / Sprite buffer calls, but where the test mode of one of the 3D games writes data directly rather than triggering DMA / Sprite buffering. V Shoot leaves a garbage value in the list, presumably this would be erased by a DMA call that copies the correct list. MAME does buffer the sprites, but automatically, every frame, to a private buffer. I think instead the sprites should be buffered based on a write, to a CPU visible area (the 'secondary' list) Ideally tests need doing on the hardware, to see if there's a call / write which copies the list we're using over to the addresses of the secondary list, drawing both lists was almost certainly wrong however. What I need to look for is cases where the secondary list is used (I think it's only that one test mode) and see if there's a register that is different, or a write that doesn't happen every frame in that case.

No.19601

Osso

Moderator

Dec 26, 2021, 08:17

No idea of the commit which fixed this.

No.19602

Haze

Senior Tester

Dec 26, 2021, 12:18

edited on: Dec 26, 2021, 12:25

I disabled the drawing of the secondary list for this driver with one of my commits while working on the sprite device, I'm 99% sure the secondary list is a buffer where data gets copied by DMA / Sprite buffer calls, but where the test mode of one of the 3D games writes data directly rather than triggering DMA / Sprite buffering.

V Shoot leaves a garbage value in the list, presumably this would be erased by a DMA call that copies the correct list.

MAME does buffer the sprites, but automatically, every frame, to a private buffer. I think instead the sprites should be buffered based on a write, to a CPU visible area (the 'secondary' list)

Ideally tests need doing on the hardware, to see if there's a call / write which copies the list we're using over to the addresses of the secondary list, drawing both lists was almost certainly wrong however.

What I need to look for is cases where the secondary list is used (I think it's only that one test mode) and see if there's a register that is different, or a write that doesn't happen every frame in that case.