Graphics rendering

The problem is not insurmountable.  LUT's are one possible solution.  And
some of these solutions consume quite a bit of FPGA resources and might be
quite complex.

The original reason for my post (which got lost pretty quickly) is to sort
of do a survey of available (or well-known) techniques.  Based on the
response, I gather that this is so rare that very little, if any publicly
available literature might exist.


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

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

>Bypassing the frame buffer means you need to have some fast algorithm to do
>some fast drawing. Correct?

[Serious old-fart alert.]

In the old days, they made vector displays.  The beam had X and Y addresses
that you could control rather than a raster scan.  You could draw
individual points.  To make a line, you could draw a sequence of points,
or use the line drawing hardware assist.

Typically, you fed the displa a "display list" which was just a list
of commands with an op code set like move absolute, move relative,
draw dot, draw line...  subroutine call/return. ...

There were some amazing ideas discovered back then.  If you like
clever tricks in this area, feed "hackmem" to google and look in
the index under "display".  (HACKMEM is a collection of tricks
and hacks (in the old meaning of the word) from the PDP-6 days
at the MIT AI lab.)

Back in those days, the display technology was reasonably well matched
to the hardware for processing the display list.  I don't remember 
any hardware to do curves but it seems reasonable.

The CTSS machine (modified IBM 7094) at project MAC had a display
list that drew lines in 3 dimensions and did the projection to the two
dimensional screen in hardware.  All you had to do for a 3D rotate
was tweak the parameters in a rotation matrix.

That technology was OK for wire stick models.  If your picture got
too complicated the refresh time was slow and you got lots of flicker.
(The refresh time was the time to process the whole display list.)

I think some of the vector displays may have used electrostatic
deflection rather than magnetic.

If you think about high quality displays, it's hard to do better than
a frame buffer.  You get to piggyback on the technology and economics
of TV displays.

If you don't like frame buffers, you can use an LCD displays
where the buffer is included as part of the display.


Other old display technologies without frame buffers:

Early glass TTYs stored the "picture" as ASCII (rather than raw
frame buffer bits) and did the translation to pixels on the fly.
You could get TTL chips that were ROMs for 5x7 dot matrix fonts.
Some of the address bits were the character.  Some were the row
within the character that the display was processing now.  It might
be fun to build a VT-100 in an FPGA.

I think Tektronix made a family of displays using storage tubes.
No frame buffer needed.  Hard to turn a pixel off though.  You had
to erase the screen (blink, flash) and repaint what you wanted to
remain.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

> We are squarely in the real of commedy at this point.  Thanks for a good
> laugh.  I hope that was your intention.

Yes I do get quite sarcastic at times don't I?

You orignally posted your question to the group expecting a straight forward
responses.  I and others couldn't get past the mental block of not using a
frame buffer and were trying to convince you to do things the way we thought
it should be done.

You got frustrated (very understandable) and you quickly fired off a
scenario.  I suspect what you were trying to tell us in an indirect way,
"Okay guys, I know you don't think it can be done without a frame buffer,
but let's pretend."  Unfortunately within your scenario you made the
statement:  "In addition to this, due to cost constraints, you are not
allowed to have rendering memory for the graphics overlay."  Engineers are
so anal about little details, we often miss the main point, and like pit
bulls we latched onto the claim that memory was too expensive and started to
argue with you about that, thinking to ourselves, "Poor misguided soul, the
reason he's not using a frame buffer is because he thinks memory is too
expensive.  Needless to say this increased your frustration further.

Dealing with engineers is like playing with a long piece of masking tape.
If you're not very careful a part of it will stick to you, and your
struggles to free yourself will get you into more of a mess.  I know when
people misunderstand me my first response to respond quickly and in great
length, but that usually leads to more miswording and misunderstanding.

Perhaps one approach would have been to state from the outset:  "I have
already built a device that overlays horizontal and verticle lines without
using a frame buffer.  I'm trying to add diagonals and curves now."  This
might have helped us avoid the mental block because you've "proven" it's
possible to not use a buffer.  Heh of course we probably would have said,
"Well switch over to a buffer."

Well I better stop before I start getting more long winded.  Anyways, just
some random thoughts on the situation.  My apologies for responding to your
frustration with sarcasm, and for not reading some of your words carefully
enough, and reading others too carefully.  May you have better luck in the
future.


Regards,
Vinh

> [Serious old-fart alert.]

LOL.  Thanks for the interesting trivia Hal :_)  Did you work with any of
those particular technologies?

Hey, did you hear about the progress they're making in electronic ink?
http://www.nature.com/nsu/030922/030922-10.html


--Vinh

I worked with PDP11-34's and Tek storage displays back a few (let's leave it
at that) years ago.


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

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


"Hal Murray" <hmurray@suespammers.org> wrote in message
news:vn9qqgroj34s6d@corp.supernews.com...
> >Bypassing the frame buffer means you need to have some fast algorithm to
do
> >some fast drawing. Correct?
>
> [Serious old-fart alert.]
>
> In the old days, they made vector displays.  The beam had X and Y
addresses
> that you could control rather than a raster scan.  You could draw
> individual points.  To make a line, you could draw a sequence of points,
> or use the line drawing hardware assist.
>
> Typically, you fed the displa a "display list" which was just a list
> of commands with an op code set like move absolute, move relative,
> draw dot, draw line...  subroutine call/return. ...
>
> There were some amazing ideas discovered back then.  If you like
> clever tricks in this area, feed "hackmem" to google and look in
> the index under "display".  (HACKMEM is a collection of tricks
> and hacks (in the old meaning of the word) from the PDP-6 days
> at the MIT AI lab.)
>
> Back in those days, the display technology was reasonably well matched
> to the hardware for processing the display list.  I don't remember
> any hardware to do curves but it seems reasonable.
>
> The CTSS machine (modified IBM 7094) at project MAC had a display
> list that drew lines in 3 dimensions and did the projection to the two
> dimensional screen in hardware.  All you had to do for a 3D rotate
> was tweak the parameters in a rotation matrix.
>
> That technology was OK for wire stick models.  If your picture got
> too complicated the refresh time was slow and you got lots of flicker.
> (The refresh time was the time to process the whole display list.)
>
> I think some of the vector displays may have used electrostatic
> deflection rather than magnetic.
>
> If you think about high quality displays, it's hard to do better than
> a frame buffer.  You get to piggyback on the technology and economics
> of TV displays.
>
> If you don't like frame buffers, you can use an LCD displays
> where the buffer is included as part of the display.
>
>
> Other old display technologies without frame buffers:
>
> Early glass TTYs stored the "picture" as ASCII (rather than raw
> frame buffer bits) and did the translation to pixels on the fly.
> You could get TTL chips that were ROMs for 5x7 dot matrix fonts.
> Some of the address bits were the character.  Some were the row
> within the character that the display was processing now.  It might
> be fun to build a VT-100 in an FPGA.
>
> I think Tektronix made a family of displays using storage tubes.
> No frame buffer needed.  Hard to turn a pixel off though.  You had
> to erase the screen (blink, flash) and repaint what you wanted to
> remain.
>
> -- 
> The suespammers.org mail server is located in California.  So are all my
> other mailboxes.  Please do not send unsolicited bulk e-mail or
unsolicited
> commercial e-mail to my suespammers.org address or any of my other
addresses.
> These are my opinions, not necessarily my employer's.  I hate spam.
>

"Vinh Pham" <a@a.a> wrote:

> Perhaps one approach would have been to state from the outset:  "I have
> already built a device that overlays horizontal and verticle lines without
> using a frame buffer.  I'm trying to add diagonals and curves now."

Nope.  The best approach would have been for you to have read the original
post carefully.

Let's review it:

<START REVIEW>
>> 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."

OK.  This guy understands the whole frame buffer thing and knows those
algorithms.


>> Does anyone know of any algorithms to draw primitives that work
>> without the intermediate frame buffer step?

OK. The challenge is to find a solution that does not use a frame buffer.
Therefore, I should not bother to reply if I'm going to say that he should
use a frame buffer, 'cause he already knows how to do that.  That is not
what he's looking for.  He very clearly states that he is interested in
solutions that do not use a frame buffer.

Telling him that he's a dummy for not using a frame buffer would be missing
the point alltogether.  This is not the sort of thing that's going to help
me pass my reading and comprehension test.  I should stick to the
constraints as delineated and strongly suppress my urge to go off on a
tangent that has nothing to do with the question being asked.  This, of
course, is not what I'll do 'cause I fully intend to have selective recall
of what he's asking.  I'll give him the answer I want him to hear, whether
its applicable or not.  I'm happy with my answer.  He should be happy as
well.

<COMMENT> If you know George Carlin, that is what I imagine he would say.
:-)


>> 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.

OK.  He's also naililng down the input parameters, which are simple.


>> Horizontal and vertical lines (and rectangles), of course, are easy.

OK.  Yes, he understands very well that pure H and V lines are not an issue.


>> But, how do you do curves or diagonal lines?

Aha!  He's no dummy.  He knows where things get messy.  If I were to reply,
this is where I shoud concentrate my efforts.  How do you draw curves or
diagonal lines in real time, without using an intermediate frame buffer and
with real-time pixel x,y coordintes and graphic entity parameters as your
sole input parameters?.


>> It seems to me that you'd take y and solve for x, which could produce
>> multiple results (say, a line near 0 degrees).  You'd have to save the
>> results for that y coordinate in a temporary buffer that would then
>> be used to compare to x.  That's as simple as I can come up with."

OK.  He's also proposing one possible approach.  However, the question he
posed earlier suggests that he's looking for alternative solutions or
commentary on what he is proposing.
<END REVIEW>

It was all there buddy.

Dead topic.  Move on.  Have a great weekend.  :-)

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

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

> It was all there buddy.

I am bested, I concede you the field.

> Dead topic.  Move on.  Have a great weekend.  :-)

Why thank you  :_)

Martin Euredjian wrote:
> I finished.

Isn't design work is like writing a book.  You cannot
finish, you can only abandon.

A good friend in aerospace tells me a that a common saying in those circles
goes something like this:  "At one point you'll need to shoot the engineers
and fly the darn thing or it'll never be fininshed"


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

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


"Tim" <tim@rockylogic.com.nooospam.com> wrote in message
news:bl3k40$m5e$1$8300dec7@news.demon.co.uk...
> Martin Euredjian wrote:
> > I finished.
>
> Isn't design work is like writing a book.  You cannot
> finish, you can only abandon.
>
>

Martin Euredjian <0_0_0_0_@pacbell.net> wrote:
> "Vinh Pham" wrote:
> 
>> You've got quite a set of challenging constraints there.  So you're saying
>> an FPGA is cheaper than using a frame buffer and a micro-controller?
> 
> Well, yes.  I have to process half a billion pixels per second.  Kinda hard
> to do with a microprocessor.

Just buy a NVIDIA GPU. It might just about be able to do it.

> 
>> Well if you pull this off, it'll be quite impressive.  Please let us know
> of
>> your progress.
> 
> It's nothing to warrant being impressed.  Seriously.  It's just a matter of
> implementation.
> 

But in the similar vein, hard AI is just a small matter of programming. 

-- 
	Sander

+++ Out of cheese error +++