Graphics rendering

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

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

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?

--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 snipped-for-privacy@pacbell.net where "0_0_0_0_" = "martineu"

do

addresses

unsolicited

addresses.

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

Let's review it:

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

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.

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

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

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

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

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.

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"

I am bested, I concede you the field.

Why thank you :_)

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 snipped-for-privacy@pacbell.net where "0_0_0_0_" = "martineu"

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

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

--
	Sander

+++ Out of cheese error +++

Use the function of the shape.

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

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:

Jan Gray, Gray Research LLC

Thanks, I'll go look at your article.

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

To send private email:

0_0_0_0 snipped-for-privacy@pacbell.net where "0_0_0_0_" = "martineu"

buffer

sorting

out

high

span