>I'm currently working on a demo program that includes sprite reuse and
>multiple copies. I have a lot of problems with the kernel (the 192, or >200
>for Pal, scanlines loop) because it's not obvious to know how many lines
>I've already drawn and how many are still to be drawn. This happens because
>the screen is divided into zones of different height which change according
>to various game parameters.
>I think this is a common problem as soon as games becomes complex, and you
>haven't planned everything from the beginning (tell me which Atari 2600
>programmer ever planned everything...? :-) )
Suppose there are four of these zones. One should arrange them so they
always add up to 192 lines. If they change, whether at select time or
throughout the game, the game should at least do some calculations to
make sure they add up. You could store these height values in four
different memory locations. If your loop wants to know how many lines
it has drawn, in the literal sense, it would add up the values of zones
it has drawn. If your loop wants to know how many lines it should draw,
it reads that value from memory, probably before the loop.
My demo will have three zones. Maybe four if I can put in a scrolltext.
>Now I have this idea: why don't we handle the kernel loop with a timer,
>like we do for Vblank?
>
>In practice:
>
> - start a timer for 192*76 cycles
> - begin the scanlines loop
>
>A possible problem could be that TIM64 isn't enough for so many cycles, so
>we could have to use TIM1024 followed by TIM64.
TIM1024's closest guess would probably yield 2048. I don't know if TIM64
could conceivably "add on" to TIM1024, but a clever programmer could figure
a way around it.
--
Archives available at http://www.biglist.com/lists/stella/archives/
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.
