| |
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....
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
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: 2014 |
@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: 728 |
@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: 2014 |
@HCL: My bad... :) However a jmp ($dc03) was TEH NICE. ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
lol, funny to see that every coding question results in a who can do it better debate :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
The whole demo scene is a "who is better" debate. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
other than the cracking scene ofcourse :=D |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Quote: other than the cracking scene ofcourse :=D
O'realy? :D |
| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
Thank you people, I am using the routine HCL described and it works good. I had a little bit of trouble finding out how to get the cia to start counting on the beginning of the rasterline but I added some nops etc to time it to start at the right place.
I have a question regarding the method that Groepaz suggested, I know that you can stretch/unstretch sprites on every rasterline, but how can you stretch them even more than that? Is the idea that you place a transparent sprite on the uppermost line where your sprites will be located, stretch it down until you reach the place where your real sprite should be displayed, unstretch, change the sprite pointer, display it and change sprite pointer again to the transparent and stretch it for the remaining number of lines? Isn't it going to need an awful long stretch if you are going to have an effect on a very large portion of the screen.
And while talking about stretching, if using the timing method that I currently have, there isn't enough time to change the sprite y-stretch on the lines where the borders are open, because the lda $a9 needs to be there. Is this correct? I guess it could be done if the loop is unrolled, because you can get rid of the dex and bpl. Gotta try that out :)
Cheers! |
| Previous - 1 | 2 | 3 - Next |
