| |
ZIG
Registered: Feb 2004
Posts: 37 |
Better ways to stabilizing raster when sprite multiplexing
This is an odd one. I am trying to get cycle timing correct on lines that have multiple sprites at different locations in different 'frames' of screen update. It's a repetitive multiplexer effect, so every $12 screen updates I have the same configuration of sprites cutting a given raster location.
By just using a $d012 compare (instead of the second IRQ) the variability of the initial IRQ invocation (background code is running) combined with the lower cycle count per line due to sprites makes timing variability *massive* and *inconsistent* - especially when I am trying to hit a color change on a badline.
How would one get a stable raster in this situation? Is the only answer to trigger a second IRQ during the first IRQ and then on the second IRQ lookup a preconfigured delay based on the 'frame' of sprite configuration or am I missing a simpler solution?
Appreciate any ideas. |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
faster methods use the cia timer. CIA timers count 1 tick per cpu cycle, and can count downwards continously from a given number without intervention, so if you start them at the right time they can be used to see where you are within a rasterline.
shortest CIA-stable raster
you can use then the timer value as a selfmod value to a branch, to skip the nr of cycles needed to stabling. or you can form a jmp $xxyy from the cia registers, so the irq will jump to a routine that has the exact needed delay built int. |
| |
ZIG
Registered: Feb 2004
Posts: 37 |
This sounds very promising. Will try this out... Appreciate your reply. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
btw if you only have $12 type of sprite configurations you can "simply" just code a different routine set for each of the $12 possible frames. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
If there is enough memory for two sets of sprites, i'd always go for the half-sprite technique or similar.
These allow for switching sprite patterns anywhere within the top and bottom 10 lines, without the need for cycle-exact register writes.
Doubly so for concurrent writes to switch colours, which generally does not mix well with badlines AND sprites. |
