>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.
Moving "fractional" portions of pixels/dots/whatever is handy for
rate-control and makes really fluid movement easy from the software side.
Just gives you some easy dynamic range to play with. No real reason to
"need" it though.
Actually, I bet the dot size of the (focused) beam on a 19" raster tube is
probably larger than the lower bit or two of resolution from a 12bit DAC.
(Not to mention the shadow-mask.)
This is really just the Sega G-80 vector generator at this point.
Direction (angle) described by your rise/run pairs, length of line for the
length counter. It works prety well for the Sega stuff-- the only thing
that looks a little ugly is that they perform the angle->delta conversion
in relatively low resolution so "large" objects don't rotate smoothly
onscreen. That would be avoided here since the PC can do the transform and
just send the high-precision deltas to the line engine.
>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))
That looks do-able, but at a synthesis level I'll actually need an adder
and a subtractor that gets selected based on the sign of the delta's. A
2-bit full-carry lookahead adder cell cascaded to make a 12 bit adder takes
28 macrocells... A full 24bit adder and subtractor might take the better
part of a 128 macrocell CPLD by themselves. Well, as long as I do it in
VHDL I should be able to retarget to an FPGA is worse comes to worse...
Xilinx 4000 series parts are really cheap now...
>> 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.
Gotcha. That makes sense.
>> 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.
True. Might look pretty neat on a vector screen though... 8^)
>Depends on dot count and weather or not you want to do curves. And now that
>you got me all excited about curves...
:-)
>I'll let ya know if anything else hits me ;-)
Sounds good. Zonn must be busy working. I can't believe he's resisting
from commenting so far. ;-)
-Clay
Clayton N. Cowgill Engineering Manager
_______________________________________________________________________
/\ Diamond Multimedia Systems, Inc. clay@supra.com
\/ Communications Division http://www.supra.com/
Received on Tue Dec 16 11:57:22 1997
This archive was generated by hypermail 2.1.8 : Thu Jul 31 2003 - 23:01:05 EDT