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


Forums > C64 Coding > Unexpected sprite behaviour
2018-09-22 00:30
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.
2018-09-22 00:41
chatGPZ

Registered: Dec 2001
Posts: 11108
yeah please someone explain this. it must be totally logical and expected (it works in all emus, real thing, etc) but.. wtf?
2018-09-22 07:19
Krill

Registered: Apr 2002
Posts: 2839
Quoting Compyx
although 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.
2018-09-22 14:14
Rastah Bar

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.)
2018-09-22 15:35
Krill

Registered: Apr 2002
Posts: 2839
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.
2018-09-22 19:11
chatGPZ

Registered: Dec 2001
Posts: 11108
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 :)
2018-09-22 19:24
Krill

Registered: Apr 2002
Posts: 2839
Sure it does. :) Might not be visible on your realthing setup or without VICE debug borders, but yeah.
2018-09-22 19:27
chatGPZ

Registered: Dec 2001
Posts: 11108
guess i never noticed, because usually on a screen with opened upper/lower border, there is also multiplexing going on. funky :)
2018-09-22 19:37
oziphantom

Registered: Oct 2014
Posts: 478
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..
2018-09-22 20:10
Digger

Registered: Mar 2005
Posts: 421
Schrodinger's sprite.
2018-09-22 20:10
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 :(
 
... 2 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 - Next
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
redback
AüMTRöN
Guests online: 120
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.051 sec.