Viewing Issue Advanced Details
|ID||Category [?]||Severity [?]||Reproducibility||Date Submitted||Last Update|
|00763||Graphics||Minor||Have not tried||Feb 4, 2008, 14:23||21 days ago|
|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|
|Affected Sets / Systems||vshoot|
vshoot0100u2gre.png (9,479 bytes) Feb 14, 2008, 15:18
|There are no relationship linked to this issue.|
21 days ago
|No idea of the commit which fixed this.|
21 days ago
edited on: 21 days ago
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.