Subject: Re: [stella] 6 digit score display and other ramblings|
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Mon, 16 Mar 1998 17:55:52 -0500 (EST)
> > 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!!