| |
Proton
Registered: Jul 2019
Posts: 7 |
Ghost data on the right border while opening side borders
Hello Mates,
This is an oldschool coder having kinda issue.
Since I started coding again after nearby 30 years of break, I have faced this issue more than once.
Well, ages ago, we were not able to see everything clearly as we can see now using emulator or proper adjustable display whrere you can see the real borders.
For some unknown reason, some sprites may cause ghost data appearing in the right border. approx. 5 pixels or so.
This is not happening always, so why it happens?
Is it just another bug in the bug or what?
Bug can be seen here: http://loxa.pw/fig/ghostdatabug.png |
|
| |
tlr
Registered: Sep 2003
Posts: 1790 |
It's a little hard to see exactly where we are on the line from your screenshot, but in general there will be a glitch in the sprite wherever the fetch of data for that sprite occurs. For sprite 0 that is quite early so if you are moving sprite 0 into the right border you will commonly see a glitch there. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Could be that the sprite DMA transfer(fetch) takes place at that point, if in right border, then it is a low 0-2 sprite. Or some sprite crunch effect is taking place. The VIC Article may help. Search CSDB for that. Does some vic write take place at that position? |
| |
Proton
Registered: Jul 2019
Posts: 7 |
I'm not using sprite 0 at all, but 1-2 yes, and due the priority, graphics from the topmost sprite is having that ghost data.
On that screen, I'm using sprites 1-4, and 0,5-7 are unused. I could try using sprites 3-7 if it does any change. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Yes, the glitch is there for all sprites, just in a different spot. For the right border, higher sprite numbers make the most sense. From what I remember the sprite 1 glitch was outside the normally visible range though, but if you want it 100% clean you'll have to change sprites. |
| |
Proton
Registered: Jul 2019
Posts: 7 |
That's what i said about it. I think this bug was there 30 years ago as well, but we just didn't see it. :-)
I'll try higher sprites and I'll let you know can I make it disappear.. |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Note that some of the fetch areas are likely outside the area present in the composite signal. Collisions will however still occur which can confirm their presence. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Moving sprite 0 into the right border and it having corrupted graphics is one problem, this is something else. One of my intros has a bug like that in the right border and I was using sprites 4,5,6,7. Only the first line is glitched though (and I could hide it by making the first line of a sprite black, but I ran out of space)
GTA Intro (fixed)
You can also see this problem in this old demo:
https://youtu.be/mwQbPgUpPKU?t=2168 (36:05)
I have a theory, that as soon as your sprite Y position matches the raster position, VIC will draw whatever is on the bus, it only starts reading the real data later on on that line and output it on the next one.... though that would cause glitches even in the normal screen... I don't know then :P Where's Groepaz ?? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
judging by the screenshot looks like the glitch happens on a specific xcoo, and iirc sprites glitch if they have xcoo changed while they are displayed. |
| |
Proton
Registered: Jul 2019
Posts: 7 |
Grats mates!
I managed to get rid of that glitch.
I just changed the order of the sprites.
Actual visible data from second sprite to the fourth one did the trick. Thank you very much. Yay..
Short vid about the bugs gone: https://loxa.pw/fig/ghostdatabug_gone.mp4 |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quoting GolaraMoving sprite 0 into the right border and it having corrupted graphics is one problem, this is something else. One of my intros has a bug like that in the right border and I was using sprites 4,5,6,7. Only the first line is glitched though (and I could hide it by making the first line of a sprite black, but I ran out of space)
GTA Intro (fixed)
You can also see this problem in this old demo:
https://youtu.be/mwQbPgUpPKU?t=2168 (36:05)
I have a theory, that as soon as your sprite Y position matches the raster position, VIC will draw whatever is on the bus, it only starts reading the real data later on on that line and output it on the next one.... though that would cause glitches even in the normal screen... I don't know then :P Where's Groepaz ??
This was previously discussed here: Sprite data fetch in sideborder |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: judging by the screenshot looks like the glitch happens on a specific xcoo, and iirc sprites glitch if they have xcoo changed while they are displayed.
From what I've been able to tell there is no effect when changing the x-pos of an already triggered sprite.
The theory is that the sprite shift register is loaded on the sprite data fetch and triggered when the x-pos matches, then shifts countinously (which eventually results in all zeroes) until the next fetch. Triggering again while triggered does nothing.
I'm happy to be proven wrong though. |
