RE: 137179 replacements (again)

> yeah, I figure that since they were storing every individual rotation of
> every object (don't forget the handy mirroring bits tho, MH only) they
> were really counting on using large amounts of vector ROM.
>
I'm pretty surprised just how "far" vector RAM lasts. I didn't bother
making a custom vector ROM for the menu or V-BREAKOUT. I just carry the
data around in with the program code and load it into VRAM at initialization
time. I'm probably only using 1/3rd of the RAM even. Having stuff in RAM
is nice for being able to tweak colors and whatnot on the fly. You could
store a BUNCH of sprites in the ROM area... It's safe to say that you'll
probably run out of vector generator time before you run out of RAM...

> You get the idea. You would think that they would somehow calculate the
> current beams
> position and
> then just reposition from the last vector but I guess that since like you
> mentioned, the
> scale effects
> beam positioning too. So, they sort of always have to start from the
> center reference. It
> seems to
> make up about 30% of vector code tho.
>
Yeah, moving from the last calculated position is a little tricky. It's an
analog system so (Zonn's favorite complaint about it ;-) lines don't
necessarily match up exactly. Centering the beam resets the integrators
(like on a Vectrex) and gets your precision back. I noticed that on
V-Breakout by the time the "box" around the screen gets back to the starting
point it's not quite lined up anymore. And the paddle may or may not
exactly touch the edges depending on the board, temperature etc. The game
is still all just a numeric simulation with the display being a "snapshot"
of the data, but you need to be a little careful near the edges of the
screen since "close calls" might look like direct hits by the time the AVG
draws them on the monitor.

> Yep, if you know where your vector data is going to be, you can use the
> power of
> the main CPU (fast) to save a lot of vector state machine (slow) time.
>
Agreed. My main routine runs four times before updating the display once.
That allows me to essentially "super sample" the ball position for hit
detection so no matter how fast the ball looks on screen it's always
"moving" in increments less than the size of a brick in the simulation. (So
you can't "hit" a brick in the second row without breaking through the
first. Perfect 45 degree angles can let you hit a partially surrounded
brick, but Super Breakout did it this way so I didn't change it.)

-Clay
Received on Tue Jun 8 15:38:43 1999