| |
crl
Registered: Mar 2020
Posts: 19 |
Cycle tables
I read about cycle tables in regard to one of Upfront’s demos can someone explain this concept to me? |
|
... 6 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting CompyxYes, with less sprites on a given line, you'll need to waste more cycles. Unless you have gaps between the enabled sprites. =) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Yes, indeed.
You can see that reflected in my table. The first time I set up such table (by hand for all 256 possibilities), that was a bit of a WTF moment :)
The table is less 'linear' than you might expect. |
| |
crl
Registered: Mar 2020
Posts: 19 |
Thanks. Makes sense. I guess the hard part muat have been how to determine the number of sprites on each rasterline and doing so sufficiently fast |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I use a naive approach where I first fill a table with 0's and then use ORA for each sprite:
Basically for sprite 4 (so the fifth sprite):
ldy sprite_ypos_4
ldx #20
- lda table,y
ora #%00010000
sta table,y
iny
dex
bpl -
I do this for all 8 sprites and then use the table to index the cycle-table. This obviously eats a lot of cycles and can be improved a little by unrolling the loops. But if you have a fixed Y-movement you can pre-calculate a lot of that.
I do a similar thing for the DYSP that uses $d017 stretching.
But since these articles are supposed to explain stuff, I tried to keep stuff 'simple'.
There's also a way to use a CIA timer to determine how many cycles to waste, I think Kjer/Horizon was the first to do that. That way you handle the calculation of the clock slide inside the DYSP. But that leaves fewer cycles for raster splits.
But that's something for another article, I've never done that myself, should be interesting. =) |
| |
Martin Piper
Registered: Nov 2007
Posts: 631 |
My really naive approach years ago was to hand tweak delays for each raster for each animation frame. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
also see <shameless plug>Victimer</shameless plug> |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
hmm maybe lft's collision register trick could be used here to find out what sprites are active per line ? so instead of d021 use d022 and multicolor charset filled with d022 'color'. (or whatever causes collision with sprites)
then just read out sprite-backgr collision register per line and look up cycle table with it.
edit:oh and ofcourse we need the 63 cycle stretch routine (linecrunch?) to have the d022 fill repeated without badlines |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Hmm, what does that trick do originally?
Because afaik, the collision registers reflect collisions only after the fact, once a sprite has been drawn (and depend on the actual sprite bitmap pattern), and then update only once per scanline.
I guess this prevents offsetting variable sprite DMA early enough/in the correct places within a rasterline. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
you are right, the register must be only valid when the sprites have been drawn on that line, and thats too late. |
| |
tlr
Registered: Sep 2003
Posts: 1703 |
Quote: Hmm, what does that trick do originally?
Because afaik, the collision registers reflect collisions only after the fact, once a sprite has been drawn (and depend on the actual sprite bitmap pattern), and then update only once per scanline.
I guess this prevents offsetting variable sprite DMA early enough/in the correct places within a rasterline.
The collisions do reflect collisions after the fact as you say. However the registers update "immediately" and can update more than one time on a scanline. |
| Previous - 1 | 2 - Next |
