| |
WVL
Registered: Mar 2002
Posts: 924 |
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). |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
Well step one: see what happens on a real C64 :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1423 |
It makes sense to me that the next displayed line is L+2; the fetch address update is independent of the display, and would be presumably be happening in cycles 14,16,56 and 57 as usual (cf LFT's excellent VIC Timing Chart), though I really should verify those timings at some point. It's going to be fetching a pointer and three bytes of data into the three byte internal buffer for the sprite if it's enabled, whether they get displayed or not.
I suspect you're correct about the trigger to start drawing just never occurring - does it also vanish if you change it to the other combinations of >=$d8 on previous line, <=$d7 of the line when you write to the position on cycle 39? |
| |
WVL
Registered: Mar 2002
Posts: 924 |
@CristopherJam:
I tested with values $ff-$d8 modifying to $d7 (or any value below). These all show the spriteskip. If I modify from d7 to d6 or d9 to d8 it doesn't show the spriteskip.
So it's all modifications going from d8 (or higher) to d7 (or lower) that perform spriteskip. At least when writing in this cycle. |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
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. =) |
| |
WVL
Registered: Mar 2002
Posts: 924 |
@Krill : It's obviously related to the same VIC behaviour. In the 9 sprites case, the VIC displays the data for the next rasterline too soon. In this case though nothing is displayed at all.
Also, 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? |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
Quoting WVL@Krill : It's obviously related to the same VIC behaviour. In the 9 sprites case, the VIC displays the data for the next rasterline too soon. In this case though nothing is displayed at all. Or too late wrt to the first incarnation on that line. :)
But then this effect is not very timing-critical.
All you need to do is "dance around" the beam with two X corrdinate writes per rasterline.
Sprite supposed to be displayed right (ahead) of it... then HAHA NOPE!, set sprite position to left (behind) of it.
And before it reaches that position again in the next line... HAHA NOPE!, set sprite position forward again.
Lather rinse repeat. |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
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: 924 |
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. |
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
