| |
Compyx
Registered: Jan 2005
Posts: 631 |
Unexpected sprite behaviour
While trying to hack together a linecruncher I ran into a bit of an odd situation: sprites appear where they shouldn't.
My code currently doesn't actually line crunch, since I haven't got the timing correct yet, I implemented a stable raster and basically copied the line crunch code from an old demo part I once wrote.
The weird thing is that although I only poke #$32 at the sprite Y-positions, I get those sprites at raster position 0 as well. Y-stretched since I my line crunch routine uses a $d017 sideborder stretcher to allow for something a little more interesting than just a blank space.
I figured this was a bug in VICE, but it also happens on the real deal, and even x64 emulates this correctly. So there must be some logic to this.
Anyway, here's a link to the code: https://www.dropbox.com/s/ftu9jty6r32xj9a/linecrunch-fuckup.tar..
Just run linecrunch.prg or run make if you have 64tass installed. |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yeah please someone explain this. it must be totally logical and expected (it works in all emus, real thing, etc) but.. wtf? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Compyxalthough I only poke #$32 at the sprite Y-positions, I get those sprites at raster position 0 as well. Pretty sure that's simply because both $32 and $132 (= 306) exist as valid rasterlines, and sprites don't have a register for Y-coordinate MSB (bit 8).
So VIC only matches the low-byte of the coordinate with the rasterline number, then starts drawing those sprites down in the lower border and keeps on drawing them in the next frame's upper border.
The usual fix is simply disabling sprites ($d015=0) once they're done drawing, then re-enabling them just before they're supposed to be drawn. |
| |
Rastah Bar
Account closed
Registered: Oct 2012
Posts: 336 |
Interesting. Krill is probably right. Something I wanted to look into for some time: what happens if you put sprites at line $100, for example, and keep stretching them. Can you stretch them into the upper border (I mean keep stretching for more than $37 lines)? And what happens then with that copy the VIC normally draws in the upper border. Is that replaced by the stretched one? (I suppose so.) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Yes, you can stretch (and normally display) sprites across frame boundaries, such that they extend from lower border to upper border.
As long as a sprite is being drawn, it won't be restarted. Any value in its Y coordinate register that lies within the currently-drawn sprite is ignored. So yes, the stretched sprites in your example "replace" those that would be displayed without the stretching. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Pretty sure that's simply because both $32 and $132 (= 306) exist as valid rasterlines
damn. now that you say it, it seems totally obvious =D but mmmh.... does this also happen when not stretching the sprite then? never noticed it would :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Sure it does. :) Might not be visible on your realthing setup or without VICE debug borders, but yeah. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
guess i never noticed, because usually on a screen with opened upper/lower border, there is also multiplexing going on. funky :) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
yeah this "sprite" appears in two places when you have open borders has been causing me a fair amount of pain, I had to add extra interrupt splits to make sure the right sprites are turned off and on at the right points, and add extra logic to handle the correct cases for it.. |
| |
Digger
Registered: Mar 2005
Posts: 437 |
Schrodinger's sprite. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
The "no MSB for sprite-Y" sounds logical. I've seen this happen before on my real machine, long ago. But like groepaz said, usually when you open the top/bottom borders, there's some multiplexing so it doesn't show itself quite so clearly as in my shitty code.
I think I recently found an old demo part of mine that also suffered this 'problem', never noticed a few lines of the sprites sticking out of the upper border on my breadbox with my Philips CRT, but did notice them with VICE's full borders.
Too bad this can't be abused to get "free cycles" in the upper border with sprites, shoving rasterbars behind the sprites clearly indicates the sprite steal cycles in the normal way :( |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I made the same thread few months ago. Funny that people are still getting cought by this. And yes, they will wrap around from old to new frame if you stretch it. I tried sprite crunching and that usually makes the sprites very tall. All I had to do was to crunch it every 4-5 files to make it full screen. If your sprite data is filled with the same byte of graphics ($80,$80,$80 * 21) it doesn't even matter where you crunch it and it's perfect for straight lines (pseudo vertical rasterbars) |
| |
TheRyk
Registered: Mar 2009
Posts: 2244 |
There's tons of old demos with open top/bottom border and bottom sprite stuff happening unwanted in top border, too. Back in the CRT days we didn't notice/see.
When I first opened top/bottom I faced the same but simply solved the problem by setting new Y-pos just after bottom border action but before start of new frame. However, it took some time till I discovered full/debugging borders as you can see here hehehe Neotunes 2 Light (standalone) bottom stuff not happening in top but vice versa by switching Y-pos too early (apart from not really so stable rasters in side borders as I thought)
Since I've got a good real CRT (30 kg Sony Trinitron which can do full border in "overscan" mode and even NTSC), things are easier |
