Viewing Issue Advanced Details
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
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
png file icon vshoot0100u2gre.png (9,479 bytes) Feb 14, 2008, 15:18
Relationships
There are no relationship linked to this issue.
Notes
2
User avatar
No.19601
Osso
Moderator
Dec 26, 2021, 08:17
No idea of the commit which fixed this.
User avatar
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.