Re: vectorbeam hardware

Hi Zonn, thanks for your reply.

On Thu, 25 Nov 1999, Zonn wrote:
> On Thu, 25 Nov 1999 01:28:21 -0800 (PST), Adam Wiggins <adam@angel.com> wrote:
> >The question is: when drawing a line segment, how does one achieve a
> >smooth, perfectly straight, unbroken line between points? I can do it on
> >the vertical and horizontal axis, but when I want to draw a diagonal I
> >have to regulate the velocity of the beam myself. I do this by breaking
> >the line up into an arbitrary number of segments and plotting each point
> >incrementally according to y = mx + b.
>
> You need to give us a little more description on what hardware you are
> programming. The title says "vectorbeam hardware". Does this mean you're
> programming a full Vectorbeam system (Star Castle, etc.)? Or have you
> connected some other CPU to a Vectorbeam monitor? Or are you using
> "vectorbeam" as a generic term for vector programming?

Specifically, I have connected my a couple of DACs to my PC, which are
directly outputting +-5V to the X and Y axis voltage lines of a Vectrex
monitor, and 0-5V to the Z axis. Since I'm bypassing all the hardware in
the Vectrex, I assume that this would work more or less the same way for
any normal vector monitor, except that I think some take different voltage
ranges.

I've been looking more at the schematics for some vector games (Major Havoc
and Gravitar, to be exact) as well as some of the programming info for
the Vectrex itself. My limited knowledge of electronics and the terminology
they use (like RAMP, X and Y integrator, etc) means that I haven't gotten
much out of it.

The thing that still puzzles me is that I have trouble believing that these
old games really had the processing power to actual step the beam along in
a straight line themselves. That is, I'm doing it without my trouble on
my PC, but every iteration (of which there are several hundred for each
line segment) uses about twelve floating point multiplies, four floating
point adds, and a floating point square root. (I could certainly optimize
it, but I don't need to, given the relative speed of my processor.)

So it makes more sense to me that the original vector hardware would have some
sort of analog method for controling the slope of the beam, which would
be smoother and (maybe?) simpler than doing it digitally.

The specific situation is this: when drawing a diagonal line that has a
slope other than lying on a principal axis or on a perfect diagonal, the
drawing speed of the shorter axis needs to be slowed down so that it doesn't
traverse the distance before the other beam is finished.

For example, consider the line with a slope of 1/3. It *should* look like
this:

                ___
          __.--'
       --'

Because the for every 3 "units" that the x axis traverses, the y should only
traverse one. In other words, it's moving at 1/3rd the speed of the x axis.

However, my x and y axis DACs are totally independant of one another. The
beam moves at maximum speed, so when I tell it to draw a segment from
(0,0) to (12, 4) (having a slope of 1/3, as above), it looks like this:
          _______
         /
        /
     __/

Because the y-axis moves at maximum speed, but it doesn't have as far to
go, so it completes long before the x-axis has finished.

So what I'm boggling over is: do vector games have hardware (perhaps in
the post DAC stage, but possibly prior) that regulate this so that the game
software itself doesn't need to worry about it? (Baby-sitting the monitor
seems like a pretty big waste of time that the game could be using to do
other calculations.) Or do they actually do exactly what I'm doing, which
is manually stepping the beam along? In order for the prior to be true,
at some point the inputs for the two axes would need to "know" about each
other, which I haven't seen any particular evidence for in the schematics.

Hopefully this makes things clearer, and thanks for helping out a vector
newbie.

Adam
Received on Thu Nov 25 17:47:19 1999