| |
WVL
Registered: Mar 2002
Posts: 923 |
A new VIC 'effect' : spriteskip
I'm working on a new effect and noticed a bug in my routine that I couldn't track down at first. In the end I think it's not really a bug, but an (for me) unexpected behaviour of our good old friend VIC-II. I'm calling it 'spriteskip' for now. Let me explain what I think is going on.
In my effect I had to change a sprite coordinate in the rastercode. In this case it's $d00a. Now I noticed that on a single line in my effect, the sprite appeared blank. Upon further investigation it seems it's caused by me moving the sprite to the left at the wrong moment.
The X position on rasterline R is $d8 and sprite 5 is showing spriteline L. The unexpected behaviour happens when modifying this to $d7 on the next rasterline R+1 using a normal 4 cycle store, which starts on cycle 36.
In this case, no pixels for sprite 5 are drawn at all on that rasterline. I'm guessing the VIC is checking when it has to start drawing and at the worst time I'm moving it to the left so this line of the sprite never gets started. It's like opening the sideborders by modifying XSCROLL just when the border check happens.
What puzzles me mostly is where my sprite data is at. The next line VIC just continues like normal with the next line (L+2) and the data for L+1 never gets outputted somewhere.
I can't see a use in a demo effect, but someone out there might be more inventive than me. Also it doesn't seem to be mentioned in the VIC-II article.
My questions :
- is this a new behaviour/effect?
- could we somehow avoid it? (I really really really want to avoid it and my rastercode is really toight)
- is spriteSkip a good name?
Please notice I'm on vacation and doing night coding to relax. I don't have a real C64 next to me to check if it happens there too. (Now that would be funny if VICE had it wrong). |
|
... 6 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 3065 |
Quoting WVLWhat would happen if you'd do a spriteskip on the last pixel line of a sprite jn the frame before? Would the mess be gone and the VIC display the data from the previous frame? The rubbish shifted out in the "0-th" sprite line in the right border is not due to left-over shift register contents.
It's from some left-over bus state and $3fff idle byte pattern which get fed into the shift register before actual sprite DMA happens. |
| |
Skate
Registered: Jul 2003
Posts: 505 |
I remember using this back in the 90s. I needed to mask some sprite lines for my effect. I first tried $d010. it worked in a range but at some point i messed up sprites' X coordinates just like you've mentioned to disable the sprite at that line and it worked fine. I think it's pretty much the expected behaviour. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 370 |
I guess you have msb set? If, then coordinates d8-ff belong to the positions where the Sprite softly moves out of the left border.
And this explains why the Sprite apparently skips when the coordinate is set to d7. |
| |
WVL
Registered: Mar 2002
Posts: 923 |
No, msb is clear :-) but I think it's like Krill said. The same way you make the 9th sprite, except the sprite data is lost. |
| |
Oswald
Registered: Apr 2002
Posts: 5118 |
Quote: Quoting WVL- is this a new behaviour/effect? Preventing a sprite's pattern shift register from clocking out its contents by changing the sprite's X position to left of the beam in the current line is the basis for 9-sprites-per-rasterline routines, where sprite 0 gets displayed twice.
Once with the pattern read in the previous line, then again in the same line with the new pattern read in the right but still visible border.
I don't think it's a new thing.
Quoting WVL- is spriteSkip a good name? I also don't think it needs a name. =)
I dont get this. You display sprite 0 twice by preventing it being displayed ?
for WVL, I vaguely knew about this effect, I knew that "changing sprite x pos at wrong time" may cancel displaying the sprite on that rasterline. (yes its wrong, just wanna say this is common knowledge, I was told by someone or smth) |
| |
Krill
Registered: Apr 2002
Posts: 3065 |
Quoting OswaldI dont get this. You display sprite 0 twice by preventing it being displayed ? Prevent in one line, display twice in the other.
Gratuitous Alternative Fishbomb Intro around $6000 for an illustration. =) |
| |
Oswald
Registered: Apr 2002
Posts: 5118 |
Quote: Quoting OswaldI dont get this. You display sprite 0 twice by preventing it being displayed ? Prevent in one line, display twice in the other.
Gratuitous Alternative Fishbomb Intro around $6000 for an illustration. =)
ah ok I had no idea its blanked like this I thought its sprite prority maybe behind $3fff or make sprite color same as background, but yeah ghost byte doesnt work for border. and maybe something else comes in the way for the color solution. |
| |
tlr
Registered: Sep 2003
Posts: 1802 |
Quoting WVLAlso, I just had an idea where it might be possible to use this effect. It's like the 9 sprites thing, but different. Every coder has run into the 'sprite mess in the right sideborder thing' when opening the sideborder in the line just above where the first sprite would normally be drawn. What would happen if you'd do a spriteskip on the last pixel line of a sprite jn the frame before? Would the mess be gone and the VIC display the data from the previous frame?
How the first line fetch behaves was previously discussed here: Sprite data fetch in sideborder |
| |
Copyfault
Registered: Dec 2001
Posts: 483 |
Thanks for the pointer@tlr... was about to bring this up, but no csdb-access at my workplace.
While the term "spriteskip" is good and describes what happens, I also don't think that it's a "new effect". It's basically like Krill already explained: the trigger condition for starting the pixel mixing of the VIC internal sprite pattern registers and the background gfx is circumvented by switching the sprite's x-position at the right moment.
I did some examinations quite some time ago, and if I'm not mistaken (taking your example, WVL) the VIC-internal sprite x-position counter is $d8 at cycle#39 (where the W-cycle of a STORE-command starting at cycle#36 will end up). So if you set it to $d7 in this very moment, the condition for mixing in the sprite pixels will fail. The content of the VIC-internal sprite pattern registers will most probably get overwritten when the DMA-sprite-fetch cycles happen later on that line, but this would've to be examined by some fancy gadgets like that BeamRacer (or maybe by setting the x-pos again so the condition'd match _before_ the next DMA-sprite fetch cycles happen).
As good as the mighty VIC article might be, I somehow think it lacks a bit of in-depth descriptions of what the VIC does internally, especially how the pixel sequencer works and how the output is connected to the half-cycles per rasterline. IF my interpretations are correct, the mixing of the pixel data happens 2 cycles before the actual output. Should create a 126 half-cycle sheet one day and try to assign all actions of the VIC to these, but then again, lft's sheet already comes close :D |
| |
Martin Piper
Registered: Nov 2007
Posts: 739 |
It's more of a SpriteRowSkip rather than a SpriteSkip, which could be abbreviated to SRS instead of SS (*cough*). |
| Previous - 1 | 2 - Next |
