> > The standard does a wsync on each line too, but it uses every one of the
> > other 71 available cycles. If we could get a look at your source, it'd be
> > great.
>
> Okay - it's just the same then - 3 cycles "spare" on each line, since
> a WSYNC isn't necessary, as long as you've synced it up earlier, and
> use exactly 76 cycles per line. You did mean 73, not 71 cycles above,
> right? :)
I meant 71 - see my previous message. I'm fairly sure I tested this a
while back... It *might* have been 72, but I'm almost completely sure that
beginning a STA WSYNC on cycle 74 will make it not catch the end of the
current line.
> Ah, I see what you mean... I needed a 2 cycle instruction to get new
> data in any one of the 3 registers - txs is the only one I know of
> that can do that.
Oh, you mean you needed a 2-cycle instruction so you could squeeze it in
between the STA GRPx's? That makes sense then.
> What sort of colour changes? A unique colour for every scan line? Or
> something fancier? Of course, it's easy to get every 2nd 8 pixel chunk
> a different colour :) Why use wsyncs if they're not necessary? Is
> there
> something I don't know? Or is it just to show that there's at least 3
> cycles free? :)
One color change per scanline would be about as good as you could do.
Wsyncs make programming cleaner, and I think some of the emulators work
better with them, but they're not necessary if the code doesn't branch
(the cycle counts are constant.) And it's certainly easier to use a wsync
if you only need to do a few instructions on a line, instead of writing
out a few dozen NOPs.
> I would think that it would be pretty easy to move a big sprite around
> _if_ you wrote individual routines to handle the whole bunch of cases.
> There isn't enough time left over to make one general purpose loop.
That's the general consensus around here. Actually (brain flash) it just
might be possible, if you don't use wsyncs. Follow me here: you position
the sprites a line or two ahead of time. Then, you use self-modifying
code to generate a delay with single-cycle precision. This delay matches
the position of the sprite on the screen. Then, you go straight into the
loop, which already has its timing correct! Example: suppose the
megasprite usually begins at pixel 79 on the screen (pixel 147 from
vblank.) Suppose the loop normally begins on cycle 62. To shift the
sprite right by 30 pixels, after positionging the sprites, all you need to
do is delay an extra 10 cycles before beginning the loop - since we
shifted the timing of the code and of the sprite by the same amount, it
displays fine in the new location!
This'll only work if there's at least a two-thirds-cycle leniency in the
code, so you can use HMOVE to get single-pixel resolution, but that looks
possible. It'd take two lines to set up - one to generate the delay and
position the players, and another to actually execute the delay (the loop
will begin somewhere on the latter half of this line, depending on how
long the delay was.)
Will this work? If so, any ideas on how to do the delay easily? (small
enough for zero-page, so it doesn't need a SC?)
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
Don't post pirate BINs to Stellalist. Be a programmer, not a pirate.
Write the best game, win framed autographs of famous Atari alumni!!
