| |
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 |
|
| |
ready.
Registered: Feb 2003
Posts: 441 |
I have seen this before, probably even tried to get rid of it, but then in the end on a real C64 is hardly noticable, so given time pressure for X2012 it remained there:
 |
| |
Smasher
Registered: Feb 2003
Posts: 519 |
I've noticed it too in the past by opening the border and doing inc $d000. But Scan discovered it can be controlled by altering $3fff.
now let's make a demo about it! :) <- this sentence is copyright by... :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
This behaviour was previously discussed and explained here: Sprite data fetch in sideborder |
| |
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: 474 |
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: 2968 |
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. |
... 4 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
