Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > Glitchy buggy sprites when putting them in the sideborder
2020-12-29 16:55
Lord Crucifier

Registered: Feb 2004
Posts: 35
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.
2020-12-29 17:35
Krill

Registered: Apr 2002
Posts: 1743
Quoting Lord Crucifier
My 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.
2020-12-29 19:15
Lord Crucifier

Registered: Feb 2004
Posts: 35
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.
2020-12-29 21:57
Krill

Registered: Apr 2002
Posts: 1743
Quoting Lord Crucifier
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.
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.
2020-12-29 22:16
Groepaz

Registered: Dec 2001
Posts: 9716
Quote:
That cannot really be avoided

It can! Did you miss the dummy-accesses thread? :=) See example in No More Secrets V0.95 :)
2020-12-29 22:17
Copyfault

Registered: Dec 2001
Posts: 373
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.
2020-12-29 22:18
Copyfault

Registered: Dec 2001
Posts: 373
Quoting Groepaz
Quote:
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 ;)
2020-12-29 22:21
Krill

Registered: Apr 2002
Posts: 1743
Quoting Groepaz
Quote:
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
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Fabs/Hokuto Force
Viti/Hokuto Force
psych858o/MSL/Elysiu..
Lynx/ΤRIΛD
Nightlord/Glance
Grue
tlr
iAN CooG/HVSC
Hydrogen/Glance
Chris-Do
Guests online: 114
Top Demos
1 Christmas Megademo  (9.7)
2 Uncensored  (9.6)
3 Edge of Disgrace  (9.6)
4 Unboxed  (9.6)
5 Coma Light 13  (9.6)
6 Memento Mori  (9.6)
7 Lunatico  (9.6)
8 Comaland 100%  (9.6)
9 The Shores of Reflec..  (9.5)
10 Protogeo 100%  (9.5)
Top onefile Demos
1 Copper Booze  (9.8)
2 To Norah  (9.8)
3 Lovecats  (9.6)
4 Elite Code Mechanics  (9.6)
5 The Sprite Demo  (9.6)
6 Square Booze  (9.5)
7 Daah, Those Acid Pil..  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Hyperborea  (9.5)
Top Groups
1 Booze Design  (9.4)
2 Censor Design  (9.4)
3 Fossil  (9.4)
4 Oxyron  (9.3)
5 PriorArt  (9.3)
Top Original Suppliers
1 hedning  (9.8)
2 Derbyshire Ram  (9.5)
3 Irata  (9.2)
4 Jazzcat  (8.9)
5 Secret Man  (1.4)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.05 sec.