| |
Fresh
Registered: Jan 2005
Posts: 101 |
Changing definitions of 8 sprites on badlines
This is based on something I've been talking about on http://csdb.dk/forums/?roomid=11&topicid=117493, I didn't want to flood that thread with stuff that wasn't strictly related to Rudi's question.
I've written a simple test program to show that a STx is enough to change charpage (and so sprite defs) after preceeding sprite DMA and before badline DMA: https://www.dropbox.com/s/llnjj9vfwtiifmt/sprtest.zip?dl=0
The program starts with the correct values but you can use your joy on port 2 to do the following:
- move the cycle with left/right
- change the affected i/o port ($d016/$18/$20/$21) with up/down
Edit: source to be assembled with kickass |
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
give binary too :) do you also have 8 sprites before and after STx ? |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
The attached file contains both the source and the binary.
Yes, I'm dealing with the second line of the 8 sprites. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
the line where the sprite shape changes is 1 line after the badline, so it either doesnt works, or I dont understand how this demonstrates that it does. |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
The sprites are displayed one line after their definitions are read so here the problem is changing line 2 (the one following BL) without affecting line 1.
It works like this:
ldx #newvalue
ldy #oldvalue
1: stx $d018 ; first 2 (R,R) cycles
=> fetch line 1 of sprites
1: stx $d018 ; last 2 (R,W) cycles
=> char DMA (Badline)
=> fetch line 2 of sprites
2: sty $d018 ; recover original defs
If instruction 1 is too early the change will affect both line 1 and 2; if instruction 1 is too late it won't affect any of them.
Changing line 1 or 3 is trivial, you don't even need a stable raster routine. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Thanks, I get it now. I wonder why couldnt I do it back then. |
| |
Smasher
Registered: Feb 2003
Posts: 512 |
very interesting. thanks! |
| |
DKT
Registered: Aug 2004
Posts: 96 |
I've made a walk-around in Forever Lost for this problem. "Forever Lost" logo in intro is using 8 sprites in a row. There is hires scrolling background.
I was rewriting sprite content during sprite display.
I was copying last pixel row of next sprites row to the previous sprites row already displayed and was changing $d018 one line before bad line. I was displaying new sprite definitions (in last line) but it was still the old sprite.
It's not a clean solution and would be horrible for multiplexer but for a stable graphic just worked :). |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
That's basically what Groepaz called the "Overlapping data trick" in Rudi's thread.
Yes, it may be considered a bit less cleaner, but it's often a faster and safer solution in many situations. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
for a lot of situations its the perfect solution actually :) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
A short little codebase article on this, anyone?
http://codebase64.org/ |
