| |
Lord Crucifier
Registered: Feb 2004
Posts: 47 |
Glitchy buggy sprites when putting them in the sideborder
My dear homies,
I'm scrolling some multicolor sprites through the side border. No big deal: just a max of two sprites per raster line. Thing is, at certain position, each sprites starts to glitch. It disappears, comes back, leaves some ghost pixels trailing... It's all very shitty.
I've posted some screenshots on the social media website: https://twitter.com/PixelAmbacht/status/1343942287269769216
My hunch is that this is caused because the sprite data is being read on those cycles. Yet with the C64 Debugger I see no changes in DMA or other registers. At least not that I can discern with my puny little brain.
I've spend a lot of time eliminating other causes: X pos being fucked with by other code, MSB being set wrong, sprite registers e.g. multicolor maybe interfering... But to no avail.
I've seen six million C64 productions doing this right, and I'm interested in being 6,000,001 who got it right. Any advice is greatly appreciated. |
|
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting Lord CrucifierMy hunch is that this is caused because the sprite data is being read on those cycles. Correct. The usual remedy is simply to always have the sprites in the same ascending order (sprite 0 leftmost in left border, then sprite 1, ..., sprite 7 rightmost in right border) and do the hardscroll by exchanging the sprite pointers instead (or render to sprites directly).
So just make sure that a sprite's display area never crosses its DMA window on a rasterline. |
| |
Lord Crucifier
Registered: Feb 2004
Posts: 47 |
Gotcha. Thanks for the explanation. I was considering using one sprite (since I'm only showing one at a time) that has it's DMA window outside the visible field, and multiplex that sprite so I can occupy all the spots I need.
Weird thing is that seemingly all of them also have a glitch on the right side of the border, including sprite 7. For my current situation I can hide it relatively easily, but for more complex sprite stuff I guess this'd fry my brain even more. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting Lord CrucifierWeird thing is that seemingly all of them also have a glitch on the right side of the border, including sprite 7. For my current situation I can hide it relatively easily, but for more complex sprite stuff I guess this'd fry my brain even more. Hmm, you mean the pattern appearing one line above the actual sprite proper in the far right border, especially noticeable when scrolling it in? That cannot really be avoided, iirc, but hidden relatively easily, as you have stated.
Either not open the sideborder there just yet (when there is no sprite in the left sideborder on the following rasterline) or set the relevant sprite colours to background or have the same sprite be there already (multiplexed in Y) but with an all-0-pattern. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
Quote:That cannot really be avoided
It can! Did you miss the dummy-accesses thread? :=) See example in No More Secrets V0.95 :) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
I stumbled across this oddity some years ago and started a discussion back then: Sprite data fetch in sideborder.
It turned out that for sprites that are activated in a specific line their display will begin after cycle#58 and thus be visible when the sb is deactivated. Depending on the sprite number and the x-position, no sprite-data-fetches have been done before, but you see some pixel pattern nontheless. Luckily this can be completely controlled, see the thread linked above. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting GroepazQuote:That cannot really be avoided
It can! Did you miss the dummy-accesses thread? :=) See example in No More Secrets V0.95 :) Wow, that was quick. Was about to add that there is (kind of) a "distilled version" of the above mentioned thread in the ever-ruling No-more-secrets-doc ;) |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting GroepazQuote:That cannot really be avoided
It can! Did you miss the dummy-accesses thread? :=) See example in No More Secrets V0.95 :) Indeed i seem to have missed that nugget. Copied verbatim for ease of reference:Sprites far right in the border
To feed data to the sprite pattern pipe for a sprite that is displayed “far right” so it did not yet have
its DMA cycles before you can use a
STA VIC_REG, X
at the correct position in the rasterline, s.t. the 4th cycle occurs at the first sprite DMA-cycle and the
5th (the W-cycle) at the 2nd sprite DMA-cycle. This way the sprite pattern byte is filled with:
1. byte read in 4th cycle from the (uncorrected!) VIC-address
2. ghostbyte
3. byte stored in 5th cycle |
