| |
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: 11116 |
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: 2845 |
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. =) |
... 6 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
