| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Release id #148493 : GhostbyteInSprite
Seems to be related on what vic find "on bus" when try to display "unfetched" sprites data (look what happen just moving previous sprite):
https://www.dropbox.com/s/xwauy6iazhapdgc/sprites-01.jpg?dl=0
https://www.dropbox.com/s/p8tddep3bovgka0/sprites-02.jpg?dl=0 |
|
... 4 posts hidden. Click here to view all posts....
|
| |
Scan
Registered: Dec 2015
Posts: 111 |
@tlr Thanks! That's indeed the thing I ran into! Interesting read, I've never ran into this behaviour before. Then again, previously I've never done opening the sideborder before ;) |
| |
Smasher
Registered: Feb 2003
Posts: 519 |
thanks tlr! better discover those VIC bugs twice than never discover them :) |
| |
Copyfault
Registered: Dec 2001
Posts: 475 |
I'm happy to see that other C64 fellows also have stumbled across that interesting sprite data issue I was wondering about some time ago...
Did a test prog for it back then called Sideborder Sprite Data Fetch TestProg. Don't know if mine is seriously different to the one Scan did but at least it copes with the very same topic ;)
@tlr: thanks for the pointer to the original thread! |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Earlier emulator versions (of VICE, anyways) didn't properly (or at all) emulate this, which i then exploited for +h Emu-Fuxx0r V2.0 :D |
| |
algorithm
Registered: May 2002
Posts: 705 |
One other point of interest is that dependent on X position (If the sprites are at the non-visible left section of the screen), some area's of the sprite are 32 pixels wide and not 24. the last 8 pixels are the repeated last pixel definitions. See example below.. (This is using X64SC)
https://www.dropbox.com/sc/j21arhuoo794iy2/AABRnO7Gz_TM9vLmd6CS.. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: One other point of interest is that dependent on X position (If the sprites are at the non-visible left section of the screen), some area's of the sprite are 32 pixels wide and not 24. the last 8 pixels are the repeated last pixel definitions. See example below.. (This is using X64SC)
https://www.dropbox.com/sc/j21arhuoo794iy2/AABRnO7Gz_TM9vLmd6CS..
Is that really reproducible on the real hw?
EDIT: ah, that's not sprite 0? Maybe it's just the glitch around when new data is fetched. It can visibly appear if sprite 0 is moved far right. And it does not seem 100% the same on all hw. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
calls for a test program :) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: Is that really reproducible on the real hw?
EDIT: ah, that's not sprite 0? Maybe it's just the glitch around when new data is fetched. It can visibly appear if sprite 0 is moved far right. And it does not seem 100% the same on all hw.
I have no way of seeing it on the real hardware as this occurs on the far left of the debug border. iirc (need to look at the code again), sprites 5-6 and 7-8 are stacked on the side borders and I had moved sprite 6 and 8 to the left (sprites 6 show the 8 pixel addition but this is removed pixel by pixel when shifting the sprite to the right. (Ghost byte is also clearly visible in the screenshot)
Could be sprites 0-3 that I used.. will have a look later. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
There: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC..
The reason there are no references here is that I found some anomalies with collisions around when the coordinates flip over to the next display line. Basically there would be a jittery (temp dependent?) pixel change there. The fetch area as in the above example would also differ slightly between individual machines.
I need to go over that again if we need more accuracy here.
In general I stopped tweaking emulation at points where process/voltage/temperature came into play. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11357 |
ha, was going to suggest the spritescan program =) (as you can see i touched it some days ago...) |
| Previous - 1 | 2 - Next |
