| |
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.
|
|
... 15 posts hidden. Click here to view all posts....
|
| |
enthusi
Registered: May 2004
Posts: 675 |
I like timers but jumping into them is new to me. Evil. Beautyful. |
| |
Jetboy
Registered: Jul 2006
Posts: 213 |
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: 5017 |
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: 1989 |
"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.
|
| |
HCL
Registered: Feb 2003
Posts: 716 |
Appearantly the question was not about 2x2- or 4x4-timing, but having random y-position of sprites with open sideborder. Ninja's 2x2-timing is beautiful, but totally useless here.
Ok, the only thing you really need to do is setting up a timer counting down from 62 to 0 infinitely. Then you simply stabelize your timing every line by the vaue of the counter. One example:
ldx #no_of_lines
loop:
sec
lda #62
sbc $dd04
sta *+4
bpl *
lda #$a9
lda #$a9
lda #$a9
lda #$a9
lda #$a9
lda #$a9
lda #$a9
lda #$a9
lda $ea
dec $d016
inc $d016
!?!?nops??
dex
bpl loop
|
| |
Style
Registered: Jun 2004
Posts: 498 |
I used this technique for a simple DYSP I recently wrote.
Every line I would jmp indirect to the timer which would compensate for lost cycles due to sprite data reads.
Works well. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
@HCL: I'd say your method with reading the timer and compensate, and using "indirect" jump in the timer-io with NMI-triggering is quite the same.
Your method doesn't need NMI-setup time and interrupt ackknowledge, but on the other hand it has to read the timer value explicitly and apply logic, where as the interrupt approach don't.
Dunno which is most efficient, but the underlying principle is exactly the same. |
| |
HCL
Registered: Feb 2003
Posts: 716 |
@JA: You're just confusing by introducing interrupts, and starting to talk about FLI-timing. It's a rather complicated way of solving this, that's my whole point. This guy started to learn this February, common <:).
..and yes, you can of course replace the whole branch-thingie with..
dec $d016
inc $d016
jmp ($dc03)
..if you can affort a code-explode :). |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
@HCL: My bad... :) However a jmp ($dc03) was TEH NICE. ;) |
| Previous - 1 | 2 | 3 - Next |
