Re: Sega Multigame and Vector Generator Card...

> >And what if you just used 24 bit adders and did fixed point (x,y) += (dx,yd)?
> >You would eliminate the subtractor & the comparator. This is the 90's, we
> >don't use Bresenham any more (see bitmap rotation source on my web page). Of
> >course part of the vector setup would involve a divide but you could keep
> >that on the PC.
>
> Hmmmm. Ok, so let me see if I'm following you in theory...
>
> Define a 24 bit fixed point format like...
>
> xxxxxxxxxxxx.yyyyyyyyyyyy
>
> 'x' is the whole part, 'y' is the fractional part.

Yup
[...]

> So what would the "vectorlist" look like that gets fed to the line-draw
> engine? A start point and a series of delta's? (That'd be kinda cool
> 'cause you could do curves and splines... at the expense of lots of RAM for
> the vectorlist.)

start point (X,Y) , Delta (dx,dy) and number of points. The start and end
points could be specified with only the integer bits, while the deltas
could be only the 1-bit and the fractional part i.e. x.yyyyyyyyyyyy Also,
the fractional part need only have as many bits as the pixel counter - if
you plot 512 "dots" you only need 9-10 fractional bits since any error
smaller than that wouldn't add up to 1 after 512 dots. I'm assuming that
you won't want to move more than "one dot" at a time (i.e. dx<=1, dy<=1)
so you don't need the extra bits in the "vector list". Of course if the
integer bits are not specified, you'll need to sign-extend what is there.

If you add (ddx,ddy) to (dx,dy) each itteration, you'll be able to do
parabolas (don't try this with an analog version :) and so-on to the
higher order curves... These start to want more precision, but maybe not
any more bits i.e. ddx = +/- 0.0000xxxxxxxxx to be added to dx. This type
of thing would be WAY cool but would complicate things quite a bit unless
you start routing all the data through the same adder! How's this:

Add dx,ddx
Add dy,ddy
Add X,dx
Add Y,dy
dec Count
loop Count>0
Output (int(X), int(Y))

All using 24-bit fixed point.

> For straight lines it seems like you'd want a comparator on the upper 12
> bits to stop a line draw when the destination is reached?

Just count dots.

> That's kind-of a neat idea. You could even do intensity control depending
> on the magnitude of the delta that's added to each line position counter.
> Interesting.

Yup, but now that you mention it, the same thing would affect intensity on
the curves - of course those are just a possible bonus feature.

> Like:
>
> Position Delta End
> 0,0 .02,.03 2,3
> 0,0 .04,.06 2,3
>
> Create the same line, but the top one does it in 100 "clocks" and the
> bottom one does it in 50 "clocks". Interesting.
>
> I bet you wouldn't need full 24 bit adders either...

Depends on dot count and weather or not you want to do curves. And now that
you got me all excited about curves...

> >Just some thoughts...
>
> Keep 'em coming! Nothing cast in stone yet, just tinkering with ideas
> still. If Zonn tells me an easy way to make Bresenham's algorithm
> self-clocking I'll probably still try that. (It kinda looks like
> Bresenham's stuff would actually run without any sort of clock... A clock
> could then be used to just synchronize the outputs. Have to get farther
> into the problem first...)

I'll let ya know if anything else hits me ;-)

-- 
 ___   __   _   _  _
|   \ /  \ | | | || |       phkahler@oakland.edu     Engineer/Programmer
|  _/| || || |_| || |__     " What makes someone care so much?
|_|  |_||_| \___/ |____)      for things another man can just ignore. " -S.H.