| |
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? |
|
| |
Compyx
Registered: Jan 2005 Posts: 631 |
The most obvious thing I can think of is tables that contain clockslide values for various situations, such as DYSP's, where the number of cycles to 'waste' on a given rasterline differs depending on what sprites cover that rasterline. That way you can do rastersplits/open the border.
Shameful plug: here's an article at codebase64 I wrote about using such a table to create an 8-sprite DYSP:
https://codebase64.org/doku.php?id=base:dysp_cycle_table
Upfront use some addition cleverness in that they do multiple smaller clockslides to get their rastersplits more stable. |
| |
Martin Piper
Registered: Nov 2007 Posts: 634 |
Compyx nice explanation and good to see example code in github. |
| |
Kruthers
Registered: Jul 2016 Posts: 21 |
Compyx, excellent article. One thing though, maybe my head is a little groggy but is this a mistake?
Quote:
Now we can waste anywhere between 0 (no sprites) and 17 cycles (all 8 sprites).
I would expect to waste more cycles with fewer sprites, etc... |
| |
oziphantom
Registered: Oct 2014 Posts: 478 |
between means there are numbers in between so 0 cycles for 0 sprites and then 17 cycles for 8 sprites and so between 0 and 8 give between 0 and 17 cycles. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11113 |
what he means is that - to compensate - you have to waste more cycles when less sprites are active. |
| |
Compyx
Registered: Jan 2005 Posts: 631 |
Yes, with less sprites on a given line, you'll need to waste more cycles. I'll update that sentence to make it more clear. |
| |
Krill
Registered: Apr 2002 Posts: 2839 |
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: 634 |
My really naive approach years ago was to hand tweak delays for each raster for each animation frame. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11113 |
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: 2839 |
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: 1714 |
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. |