| |
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....
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
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: 11114 |
other than the cracking scene ofcourse :=D |
| |
Jetboy
Registered: Jul 2006
Posts: 213 |
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! |
| |
Stryyker
Registered: Dec 2001
Posts: 465 |
What you can do is have the first sprite line empty. You can stretch one sprite the whole screen if you wish. You stretch the blank line until you come to where you want it then turn off the stretch. It means eachraster line needs code to keep stretching (or not stretch).
With changing sprite pointers you can make 1 sprite have the detail equivalent of multiple sprites layered in the Y direction.
Say you stretch each sprite line 5 times you get 165 lines for the same sprite, like:
sprite line: sprite pointer:
0:0
0:1
0:2
0:3
0:4
1:0
1:1
1:2
1:3
1:4
2:0
etc.
So line 0 is shown for 5 consecative lines but by changing the sprite pointer it shows new data. Also on the last line of the 5 line stretch you don't stretch so the VIC internal counters move on to the next line. By being creative with how it is used you can do many things once impossible. |
| |
Jetboy
Registered: Jul 2006
Posts: 213 |
You may wonder how can you change multiple sprites this way - each would need pointer change each line - so it seems too cycle consuming. There is solution to that - switch character screen memory location each line - this way sprite pointes change for all 8 sprites at once (they are stored at the end of character screen memory - so they change with character memory change). This however is only good if you dont require asynchronic streches, coz this method fails there.
And i guess unroling the loop is the way to go. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
when i coded this (looooong ago .=D) i just used d017, with a blank first line in each sprite like jackasser explained. then you just need one register write each line which modifies all 8 sprites. (and the table for d017 changes can be calculated outside the rastercode). |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
I've done DYSP at various times using either NMI interrupts or a method very similiar to the one HCL outlined above. The NMI versions were more trouble than it was worth and had some rather bizarre bugs, but that's more than likely due to my inability to code in a way that any normal person would do it than anything else.
Incidently, I once made an intro for PARALAX that had DYSP capability built in for the sideborder scroller, but never got around to actually installing the extra code to move each sprite individually in Y. So the scroll just bounced up and down as a whole. Talk about a wasted effort!
|
| |
Mantiz
Account closed
Registered: Apr 2006
Posts: 36 |
I simply can't thank you guys enough for your help on this subject. Finally understanding how things are done means a lot for me. I guess for seasoned coders, this stuff is child's play. It'll be a while before I know enough to be able to contribute with my knowledge, but I hope you like beer in case our roads will cross someday... :-)
|
| Previous - 1 | 2 | 3 - Next |
