Graphics rendering

Martin Euredjian wrote:

> I know about the various algorithms to draw lines, circles, etc.  All of
> these pretty much rely on painting onto a frame buffer that is later used
> to scan out to a CRT.
> 

Use the function of the shape.

> Does anyone know of any algorithms to draw primitives that work without
> the
> intermediate frame buffer step.  In other words, the algorithm's input
> would be the current x,y pixel being painted on the screen and the desired
> shape's
> parameters.  Horizontal and vertical lines (and rectangles), of course,
> are
> easy.  But, how do you do curves or diagonal lines?
>

For a circle:
  (x - x0)^2 + (y - y0)^2 = r^2
Test for equality (or close to equality) for each pixel position (x,y)
Circle center = (x0, y0).
Circle radius = r.

Lines:
  kx*x + ky*y = y0

In addition you vould need some limiter.

  kx*x + ky*y = y0 when 20<x<52

I have not checked the functions, but they should be close enough.

/RogerL

-- 
Roger Larsson
Skellefte&#4294967295;
Sweden

A simple and workable approach is to use one or more BRAMs as a LINE buffer
and a LINE Z buffer, perhaps double buffered for simplicity. Then by sorting
(and incrementally updating on the fly) your display list of graphics
primitives by Y coordinate and then by X coordinate, you can iterate over
them and render them into the line buffer. Works fine for Gouraud shaded
filled primitives like trapezoids too. (Textures will require more memory
ports, perhaps on-chip, perhaps not.)

So long as you can render a line worth of graphics faster than you shift out
the previously rendered line, you're looking good. No frame buffer, no high
bandwidth frame buffer memory, no frame buffer memory I/Os. Just pretty
raster graphics.

With a soft CPU core to do display list management, and a simple hardware
span-filler coprocessor on the interface to the line buffer, scenes of
limited complexity seem quite doable in even a rather spartan FPGA.  For
more complexity and more performance, move the display list manager and span
edge DDAs to hardware.

See also my 1995 article on an FPGA-based rendering coprocessor:
http://fpgacpu.org/usenet/render.html.

Jan Gray, Gray Research LLC

Thanks, I'll go look at your article.


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"


"Jan Gray" <jsgray@acm.org> wrote in message
news:QwYeb.11170$RW4.4195@newsread4.news.pas.earthlink.net...
> A simple and workable approach is to use one or more BRAMs as a LINE
buffer
> and a LINE Z buffer, perhaps double buffered for simplicity. Then by
sorting
> (and incrementally updating on the fly) your display list of graphics
> primitives by Y coordinate and then by X coordinate, you can iterate over
> them and render them into the line buffer. Works fine for Gouraud shaded
> filled primitives like trapezoids too. (Textures will require more memory
> ports, perhaps on-chip, perhaps not.)
>
> So long as you can render a line worth of graphics faster than you shift
out
> the previously rendered line, you're looking good. No frame buffer, no
high
> bandwidth frame buffer memory, no frame buffer memory I/Os. Just pretty
> raster graphics.
>
> With a soft CPU core to do display list management, and a simple hardware
> span-filler coprocessor on the interface to the line buffer, scenes of
> limited complexity seem quite doable in even a rather spartan FPGA.  For
> more complexity and more performance, move the display list manager and
span
> edge DDAs to hardware.
>
> See also my 1995 article on an FPGA-based rendering coprocessor:
> http://fpgacpu.org/usenet/render.html.
>
> Jan Gray, Gray Research LLC
>
>