On Wed, 17 Oct 2001, Joel Park wrote:
> I don't quite how to ask this, but here goes:
>
> There's been alot of talk about Timing/Counting when drawing stuff on the
> screen. And I've seen what getting out of sync with the scan line drawing
> can do.
>
> So what is the objective when counting. Lets say I'm drawing a ball that
> bounces on the screen. Do I just want to make sure the ball is redrawn at
> the same cycle count each time through my loop??
>
> Or is there even more too it, do I have to actually time so the ball is
> drawn before the scan line is drawn on the screen or something like that.
>
Your first objective when counting, is to make sure things happen at the
right time. You have to make sure your vertical blank processing is done
in time so you can start drawing the screen when it's time to do that, you
make sure each scanline of your screen-drawing routine (kernel) is 76 cycles
or less (the STA WSYNC at the end of the scanline halts the 6507 until the
beginning of the HBLANK time of the next one), you make sure your overscan
processing (if any) gets done in time for the beginning of the next frame...
Your bouncing ball example: you only actually need to draw the ball on the
scanline(s) where it's supposed to be displayed. You need to do so before it's
going to be displayed on the scanlines where it's going to be drawn. If your
ball could be at any horizontal position, it needs to be drawn during the
horizontal blank (the first 22 CPU cycles after a WSYNC), to guarantee that
it's ready to display by the time the TIA is ready to display it.
As far as the vertical blank and overscan periods, those are much less time
sensitive. You've got something like 2800 CPU cycles during the VBLANK, so
usually that's the place where you'd do your joystick checking, update
positions, decide whether or not to drop a bomb on the player, etc. Very
few games need all this time... whatever time you don't need for calculations,
you have to waste (usually by busy-waiting for a timer to expire). Overscan
is the same, except it's only 2280 CPU cycles (30 scanlines) long.
The most important reasons for counting cycles are when you're trying to do
something non-standard, like modify the playfield in the middle of a scanline
(asymmetrical playfield), or modify the data for a player in between copies
of the player (when NUSIZ0 is being used to draw multiple copies). Times like
these, you have to not only know when the TIA is going to display your object,
you have to know when it's going to be done displaying the previous copy, so
you don't modify it while it's being displayed. See my posting yesterday on
playfield timings...
Hope this helps...
B.
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
