|
Back to Vectrex Programming Tutorial Index
Vector positioning optimization
thoughts
For Vectrex Frogger I did in many cases not use BIOS
functions, but ripped them and fitted them for my purposes. This
was neccessary to fit the program into the tiny timescale of
30,000 cycles for one update round. One major cycle saving trick
was done at a late stage of optimizing. It utilizes the idle
phase during vector positioning. For some more information about
this look at the documentation of Vectrex Frogger, the sourcecode
and the 'progger.txt'. Here I will give another brief
introduction to the idea I had. In the above documented BIOS
function Moveto_d the last relevant lines of code are:
LF345: BITB <VIA_int_flags ;Wait for timer 1
BEQ LF345
The positioning is usually done with quite a large scale
factor. In Vectrex Frogger I often used $90 (or so). The above
loop does nothing but check for the timer to expire. It is an
iddle loop, that waits for nearly $90 cycles. After the loop is
finnished not a single thing is done anymore, the routine is
finnished and returns to its caller. You will see quickly, that a
wait loop like that can be used to do more than just nothing. In
a tightly packed program there are always some things to do, like
collision checking, preparing the next vector drawing,
positioning updating, decrementing timers or preparing sound
output. All these things can be done during that waiting. HALT!
Not all things, you are not allowed to do anything that
changes vector drawing relevant registers in the VIA chip, that
applies to VIA_Port A, B, Shift register, Timer 1 and possibly a
few others (control registers). That generally means, that you
are not allowed to access VIA at all, that again means, no sound
output, and no joystick inquiries, no new scaling value... But I
experienced that, with clever programming MANY things can be done
in that idle time. You do not have to worry about taking to long
either, since the timer will expire all by itself. The only thing
you have to watch out for is, that you don't finnish to early,
since if you start drawing the vector when you have not finnished
positioning the beam... well, you probably can imagine what
happens. But making sure, that positioning has correctly
finnished - all you need to do is put that little 'idle'-loop
from above at the end of your intermediate section. Voila, you
saved some really valuable time here!
The same thing can theoretically be applied to vector drawing.
With drawing vectors you must make sure, that you finnish you
intermediate stuff in time, so that you can switch the beam off
in time, otherwise you will always see a bright dot at the end of
your vectors. But generally speaking, the above optimization is
not really such a good idea while drawing vectors. Since you
usually have quite small timing figures (or at least SHOULD
have). As mentioned above, Vectrex Frogger draws all 'sprites'
using a scale factor of six. There is not all that much iddle
time left. What I did is to skip the loop entirely, since ALL
vectors I draw have the same scale value, I was able to put some
fixed code into the drawing 'idle' time, so I DID save a few
cycles here as well. But this is a field where you have to
experiment individually for your program. I had to change my
routines quite a few times, till I got them right for fitting in
that 'idle' time. One major hog was the above mentioned uncertain
time for some vector drawing related flags to arrive at the
integration hardware. On the other hand, cycles saved in the
routine for drawing single vectors is really, really, REALLY!!!
important. Since you usually draw 'sprites' consisting of many
vectors. And you'll probably draw many sprites. Imagine drawing
10 sprites, each using 20 vectors, that'll make 200 vectors. Now
imaging your optiminzed code takes for each drawn vector 10
cycles less than the non optimized code. That would save about
(or exactly in this example) 2,000 cycles. If you do a game where
you will have not much time left you will appreciate these saved
cycles very much!
For examples of the above mentioned routines look at Vectrex
Frogger.
Next page Last Page
Vectrex Programming Tutorial Index
|
|