| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
Timing with y-moving sprites
Hi,
I have been trying to figure this thing out for a while.
What I have now is a stable raster routine so opening the sideborders is for example no problems at all.
What I wonder is how you can have sprites moving in the Y direction over these lines and still keep the timing, because it will change depending on which and how many sprites there are crossing it. No need to take care of badlines is required in this example.
Do I need to use NMI interrupts or is there another way, for example do a calculation somewhere else on the screen how many sprites there will be on a certain line and from that set up an appropriate delay for every line in the sideborder/raster/whatever routine you need to be stable with a changing amount of sprites over it? I've been trying the later approach but my code gets rather messy.
|
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
one common approach is to simply NOT move them at all (not in Y atleast). stretch them down using $d017 and switch sprite pointers and/or mod the way they are stretched to simulate Y movement. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
If I were you I'd use the timing technique used by ninja in real. This is applicable here since the $d016 write is to be done BEFORE the sprite fetches. I.e. for each line you stabalize between the sprite fetches of the current line and the next and POKE the $d016. But that's just me since I'm familiar with that technique.
Basically you have a timer, in your case ticking down from 62 to 0 all the time. So:
$dd06: #<$62
$dd07: #>$62
But then you place a JMP and a 0 on $dd04/dd05:
$dd04: jmp-opcode (#$4c)
$dd05: #$00
$dd06: #<$62 (lobyte of timer)
$dd07: #>$62 (hibyte of timer)
The point the NMI vector to $dd04
$fffa: #<$dd04
$fffb: #>$dd04
What happens is that when the timer reaches 0 the NMI will trigger and jump to $dd04 (with the normal unstabile jitter).
Since the NMI-setup takes some cycles and the jitter takes some cycles the lobyte of the timer will be in the $e0-$f0 range approximatly then the JMP on $dd04 executes.
So, depending on timer jitter you will jump to $xx00 where (xx is typically $e0-$f0 approx.).
So, basically depending on jitter, independant of sprites and all other delays you will jump to a specific routine. And for example in the $e000 routine (where the delay is most sever) you need to store the $d016 immediatly, but in the $f000 routine you havn't delayed that much so add the correct amount of NOPs to hit the correct $d016 cycles.
Also, you must be sure that the NMI triggers after the sprite fetches and not inside them otherwise you'll get fooled when you NOP.
I.e. start the timer initially using a standard stable raster and make sure it reaches 0 just after the sprite fetches, or preferably as tight as possible to the $d016 write.
Well... have fun! :D
But yes... groepaz suggestion is perhaps the most common and most wize method to use. ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
jackasser: is that actually quick enough to work on every line and with a few sprites enabled? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@groepaz: Hmm yes, assuming no bad lines ofcourse. NMI setup 7 cycles, jitter max 8 cycles. Sprites 17 cycles. inc dec $d016 12 cycles. Acknowledge NMI 3 cycles (when done with a jmp to a RTI opcode before the ack io) + the rti 6. so 7+8+17+12+3+6 = 53 cycles. Then you have the JMP itself also so, an additional 3 cycles. Total 56 cycles worst case jitter.
Question is, why waste 56 cycles with this method, when there are more elegand ways to do it when it comes to this particular problem? :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
because i havent used this method before :=) |
| |
enthusi
Registered: May 2004
Posts: 677 |
I like timers but jumping into them is new to me. Evil. Beautyful. |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Once you learn ninja method you wont want to use anything else. It's beautifull, its elegant, and its fast! Especialy if you are doing every second line fli, or every 4th line fli (more elaborate duiscusion on this topic in some other thread). Surely - there is quite some memory usage with that method, so its not so good as everday solution, but it serves it;s purpose. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ninja for president \:D/ |
| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
Thanks a lot Groepaz and JackAsser for the ideas and explanation! I'm trying to learn as much as I can so I will try both approaches and see which one works best. The idea with using timers is nice and very clever.
Regards,
Mantiz |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
"The idea with using timers is nice and very clever"
Yes, but not so appropriate to use if you for instance only have a simple 8x3 sprite big logo swinger or something (with open borders). Then you simply only have two timing cases, either 0 sprites or all sprites and you know exactly when the sprites start and end so all you have to do is to do some simple self modifying timing code.
The timer method is nice if you have either 1) rather complex timing due to dynamic motion of sprites, 2) if you need to do something VIC-trickery every now and then really quick (stable that is), for instance setting up a 4x4 mode.
Using the timer approach alone for setting up a 4x4 mode won't help you add dynamic sprites on top since the $d011 write to do the FLI must take place almost directly after sprite fetch #8, but your timers must stabalize BEFORE the sprite fetches. So, unless you have equall amount of sprites all lines you have a problem, since you don't know the exact amount to NOP (due to different sprite timing), to find the correct $d011 place.
What I want to say really is that, however beautiful timers are etc. etc. they don't solve all timing problems. Sometimes you still have to manually adjust the code or use some tables due to complex y-motions of sprites.
|
... 15 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 - Next |
