PDA

View Full Version : "Real Time" High Resolution Vector Graphics



Jacob D
05-16-2010, 12:26 AM
I had hoped originally to use the propeller to display a simple bitmapped graphic on a 1280x640 VGA monitor. A few weeks back I was told here (thanks again) that due to memory restrictions this is not feasible http://forums.parallax.com/images/smilies/cry.gif, and perhaps I should look to vector graphics. So I have painstakingly re-done the art for the application using integer coordinate triangle meshes . It works very well on a 16x12 tile bitmap display (256x192px)http://forums.parallax.com/images/smilies/hop.gif, but I have once again run into the problem that despite being able to store the graphics in a reasonable size (now about 800 bytes), the Propeller does not have enough RAM for the graphics buffer at this resolution http://forums.parallax.com/images/smilies/cry.gif. Even at 640x240 (with 2x scale), there is only enough for a non-double buffered display with 2 colors rather than 4. I could work around the color limitation, but the "graphics_drv_10" only works with 4 color bitmaps (as far as I can tell) so it would require a re-write.

If I must re-write the graphics driver anyway, I got to thinking (http://forums.parallax.com/images/smilies/idea.gif Uh oh!) that perhaps the full screen display buffer is unnecessary, though I think realistically there must be three complete 16 pixel high rows in memory. 6144 longs is still reasonable, at least compared with 78600 longs..

The plan is:
1) Have something like a tile driver ("TILE") to hold bitmaps and text, feed 16 pixel lines (1280*16) at a time into one of three buffers (say, BUF0, BUF1, BUF2)
2) Have a dedicated rasterizer ("VEC") handle vector art in the previously loaded buffer - i.e. render only 1280*16 pixels.
3) Have the VGA driver clock out the third buffer, 16 pixels high
4) After the VGA driver clocks out 16 pixel-rows, all three cogs rotate one buffer (so if it was VGA-BUF0, VEC-BUF1, TILE-BUF2; it would go to VGA-BUF1, VEC-BUF2, TILE-BUF0)

Memory usage is OK, with 2400 longs for the tile map, NTE 64 for the color map, 6144 for the three block-line buffers will leave about half of the RAM for user data. The part I'm not sure about is the speed.

At 1280x480x60Hz, using a 10MHz xtal with 8x PLL for 80Mhz, each cog would get about 44k clocks and 5000 hub syncs per 16 pixel block-line. The TILE driver has to copy 1280 longs (80 longs per line, 16 pixel lines), which is 2560 hub syncs in assembly, so it's idle for half of the time, that's no problem. The VGA driver obviously works already, so I'm not worried about that either. So it comes down to the real time vector rasterizer.

At a minimum it must draw triangles. Say each triangle is stored as six consecutive words (x1,y1, x2,y2, x3,y3), then each takes 3 hub syncs to read from main memory. Between each, (9 clocks) we can do CMPs on the Y value to see if they span the block-line we're dealing with. If not, we just read the next one 27 clocks later. If it falls in the block-line, it get's filled like a polygon which means clipping...

In a worst case scenario the VEC driver needs to write to all 1280 longs in the output buffer, leaving 3700 hub syncs for figuring the triangles. Can someone who knows Propeller assembly comment on the feasibility of this idea, and the number of clipped quadrilaterals one cog could compute in 3500 clocks?

Thanks,

Jacob

Mike Green
05-16-2010, 12:50 AM
You might look at Bill Henning's Morpheus dual Prop system. This uses an external SRAM buffer for the bitmap. He's got a driver that handles 1024 x 768, but I don't think the system will do 1280 pixels per line. I think the data rate is too high for the access to the external SRAM, but I could be wrong. You might be able to run it with a faster clock (like 6MHz x 16 = 96MHz).

The dual Prop system is necessary since the memory interface requires the use of most of the I/O pins.

Chip's 1280 x 1024 pixel tile driver uses 3 synchronous cogs to do the fetching of the tiles and their serialization at the speed needed. You might be able to dynamically create the scan lines fast enough using multiple cogs, but I suspect you'd need pretty much all the cogs to do so.

mikronauts.com/downloads/ (http://mikronauts.com/downloads/)

Phil Pilgrim (PhiPi)
05-16-2010, 01:13 AM
If the resulting number of bright pixels is sparse compared to the total, you may be able to store the entire image using run-length encoding (http://en.wikipedia.org/wiki/Run-length_encoding). Then, for each line, converting from RLE to a pixmap should be computable in real display time -- especially if multiple cogs can be brought to bear.

-Phil

Bill Henning
05-16-2010, 01:33 AM
I am sorry to say that won't fit:

Memory usage: 2400 longs for the tile map, 64 for the color map, 6144 for the three block-line buffers = 8608 longs

The propeller has 8192 longs in total.

Mike was kind enough to mention my Morpheus.

If you can send me the exact timing spec for your 1280x640 display, I can see if I can tune my driver to produce that resolution.

Ideally, I need:

(in terms of pixels - ie dot clocks)
horizontal sync length
horizontal front porch
horizontal back porch

(in terms of scan lines)
vertical sync length
vertical front porch
vertical back porch

At a minimum, I need:

horizontal sync frequency
vertical sync rate

I did a quick back-of-the-envelope calculation; as long as you did not need more than 60Hz refresh, I think I can do it. I may need to run Morpheus at 100Mhz.

The driver I have for high resolution on Morpheus is quite flexible, I can adapt it to other resolutions as long as the memory and video bandwidth is there.

The driver does four colors (out of 256 choices) per pixel, with a unique four color palette per scan line.

If you cut the resolution horizontally and in half, that is 640x640, it would be easy.

Double-scanning the lines, 640x360, would be even easier.

The Morpheus video drivers also come with a GPUCOG, which implements many pasm functions :)

The catch: You have to buy Morpheus from me to use its advanced graphics, as it is a commercial product, sold at a very reasonable price.

Here is the Morpheus thread - there are photo's on pages 7-10

http://forums.parallax.com/forums/default.aspx?f=25&p=7&m=362634

There are more photo's in my 5" VGA thread -

http://forums.parallax.com/forums/?f=25&m=397282

Here is my graphics API:

PUB SetPalette(yp,clr,r,g,b)
PUB SetPaletteRange(y1,y2,c2,r,g,b)
PUB FillPalette(c1,r,g,b)
PUB WaitMS(n)
PUB plotc(xsrc,ydst,col)
PUB plot(xsrc,ydst)
PUB Pen(col)
PUB Cls(col)
PUB PutChar(xsrc,ysrc,ch)
PUB PutStr(xsrc,ysrc,strptr)
PUB PutBytes(xsrc,ysrc,bptr,bsiz)
PUB FillScreen(ch)
PUB hline(xsrc,ysrc,xtwo)
PUB Line(x0,y0,x1,y1)
PUB DrawRect(x2,y2,w,h)
PUB FilledRect(x2,y2,w,h)
PUB DrawCircle(x0,y0,r)
PUB FilledCircle(x0,y0,r)

Programs just include the "xmm_gpu" object, and use the methods above.


Jacob D said...
I had hoped originally to use the propeller to display a simple bitmapped graphic on a 1280x640 VGA monitor. A few weeks back I was told here (thanks again) that due to memory restrictions this is not feasible http://forums.parallax.com/images/smilies/cry.gif, and perhaps I should look to vector graphics. So I have painstakingly re-done the art for the application using integer coordinate triangle meshes . It works very well on a 16x12 tile bitmap display (256x192px)http://forums.parallax.com/images/smilies/hop.gif, but I have once again run into the problem that despite being able to store the graphics in a reasonable size (now about 800 bytes), the Propeller does not have enough RAM for the graphics buffer at this resolution http://forums.parallax.com/images/smilies/cry.gif. Even at 640x240 (with 2x scale), there is only enough for a non-double buffered display with 2 colors rather than 4. I could work around the color limitation, but the "graphics_drv_10" only works with 4 color bitmaps (as far as I can tell) so it would require a re-write.

If I must re-write the graphics driver anyway, I got to thinking (http://forums.parallax.com/images/smilies/idea.gif Uh oh!) that perhaps the full screen display buffer is unnecessary, though I think realistically there must be three complete 16 pixel high rows in memory. 6144 longs is still reasonable, at least compared with 78600 longs..

The plan is:
1) Have something like a tile driver ("TILE") to hold bitmaps and text, feed 16 pixel lines (1280*16) at a time into one of three buffers (say, BUF0, BUF1, BUF2)
2) Have a dedicated rasterizer ("VEC") handle vector art in the previously loaded buffer - i.e. render only 1280*16 pixels.
3) Have the VGA driver clock out the third buffer, 16 pixels high
4) After the VGA driver clocks out 16 pixel-rows, all three cogs rotate one buffer (so if it was VGA-BUF0, VEC-BUF1, TILE-BUF2; it would go to VGA-BUF1, VEC-BUF2, TILE-BUF0)

Memory usage is OK, with 2400 longs for the tile map, NTE 64 for the color map, 6144 for the three block-line buffers will leave about half of the RAM for user data. The part I'm not sure about is the speed.

At 1280x480x60Hz, using a 10MHz xtal with 8x PLL for 80Mhz, each cog would get about 44k clocks and 5000 hub syncs per 16 pixel block-line. The TILE driver has to copy 1280 longs (80 longs per line, 16 pixel lines), which is 2560 hub syncs in assembly, so it's idle for half of the time, that's no problem. The VGA driver obviously works already, so I'm not worried about that either. So it comes down to the real time vector rasterizer.

At a minimum it must draw triangles. Say each triangle is stored as six consecutive words (x1,y1, x2,y2, x3,y3), then each takes 3 hub syncs to read from main memory. Between each, (9 clocks) we can do CMPs on the Y value to see if they span the block-line we're dealing with. If not, we just read the next one 27 clocks later. If it falls in the block-line, it get's filled like a polygon which means clipping...

In a worst case scenario the VEC driver needs to write to all 1280 longs in the output buffer, leaving 3700 hub syncs for figuring the triangles. Can someone who knows Propeller assembly comment on the feasibility of this idea, and the number of clipped quadrilaterals one cog could compute in 3500 clocks?

Thanks,

Jacob

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus (http://mikronauts.com/products/morpheus/) / Mem+ (http://mikronauts.com/products/morpheus/memplus/) / PropCade (http://forums.parallax.com/showthread.php?p=894725) / FlexMem (http://forums.parallax.com/showthread.php?p=894853) / VMCOG (http://forums.parallax.com/showthread.php?p=878382) / Propteus (http://mikronauts.com/products/propteus/) / Proteus (http://mikronauts.com/products/proteus/) / SerPlug (http://mikronauts.com/products/serplug/)
and 6.250MHz Crystals to run Propellers at 100MHz (http://mikronauts.com/products/mikronauts-625mhz-crystal/) & 5.0" OEM TFT VGA LCD modules (http://forums.parallax.com/showthread.php?p=852195)
Las (http://mikronauts.com/software-products/largos/) - Large model assembler Largos (http://mikronauts.com/software-products/largos/) - upcoming nano operating system

Post Edited (Bill Henning) : 5/15/2010 5:50:41 PM GMT

Baggers
05-16-2010, 01:45 AM
My Oxygene Demo used an RLE display, with a resolution of 240x160x8bit ( that small for double buffered display ) You could use that as a starting point.
it had one display driver, and two cogs doing the run length decoding.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

HollyMinkowski
05-16-2010, 03:20 AM
It's a shame that vga monitors don't have a built in video controller that can
be used if needed to create nice displays easily :-(
Why can't they be smarter? It's like the brains were just left out to save money
since a PC has a video card.

What could it cost to have one? maybe a few dollars at most if added by the manufacturer.

I guess someone could buy cheap vga monitors in quantity and add a video controller
inside and sell them to hobbyists...is someone doing this already? Maybe someday a board
using a few prop2 chips could do this.

Bill Henning
05-16-2010, 03:28 AM
It's not just the controller chip.

It's also the memory, the NRE, manufacturing costs, marketing costs etc.

Don't worry, I have a lot of really interesting products in my development pipeline :)


HollyMinkowski said...
It's a shame that vga monitors don't have a built in video controller that can
be used if needed to create nice displays easily :-(
Why can't they be smarter? It's like the brains were just left out to save money
since a PC has a video card.

What could it cost to have one? maybe a few dollars at most if added by the manufacturer.

I guess someone could buy cheap vga monitors in quantity and add a video controller
inside and sell them to hobbyists...is someone doing this already? Maybe someday a board
using a few prop2 chips could do this.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus (http://mikronauts.com/products/morpheus/) / Mem+ (http://mikronauts.com/products/morpheus/memplus/) / PropCade (http://forums.parallax.com/showthread.php?p=894725) / FlexMem (http://forums.parallax.com/showthread.php?p=894853) / VMCOG (http://forums.parallax.com/showthread.php?p=878382) / Propteus (http://mikronauts.com/products/propteus/) / Proteus (http://mikronauts.com/products/proteus/) / SerPlug (http://mikronauts.com/products/serplug/)
and 6.250MHz Crystals to run Propellers at 100MHz (http://mikronauts.com/products/mikronauts-625mhz-crystal/) & 5.0" OEM TFT VGA LCD modules (http://forums.parallax.com/showthread.php?p=852195)
Las (http://mikronauts.com/software-products/largos/) - Large model assembler Largos (http://mikronauts.com/software-products/largos/) - upcoming nano operating system

Jacob D
05-16-2010, 04:12 AM
Thanks all for the replies. I guess I am still asking too much of a single Propeller. Bill - Check your email.

mpark
05-16-2010, 05:55 AM
Paging RossH...


Jacob,

Depending on your image's complexity, you might be able to use RossH's technique:
http://forums.parallax.com/showthread.php?p=739206
http://forums.parallax.com/showthread.php?p=743781

heater
05-16-2010, 06:24 AM
Call me old but, where I come from "Vector Graphics" means exactly that.

For example, if you want a 30" diameter radar display with maps and aircraft etc. possibly with some text annotations, possibly in colour, and if your processor only has maybe 64K RAM. What do you do?

Forward in time and you are ATARI and you want to make the Asteroids game on an 8 bit micro with not much RAM, what do you do?

Drive the x and y axis of your screen and draw vectors, that is what you do.

Anything else is not vector graphics IMHO.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

potatohead
05-16-2010, 06:33 AM
BTW, that game has been ported to the Atari 8 bit computers. A vector to raster layer was implemented, allowing the original 6502 arcade code to run on the home computer, drawing to the raster layer, instead of the CRT.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
8x8 color 80 Column NTSC Text Object (http://obex.parallax.com/objects/550/)
Safety Tip: Life is as good as YOU think it is!

heater
05-16-2010, 06:54 AM
potatohead: Yep it was. With sad result of a chunky low res raster display instead of the high res vector original.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

HollyMinkowski
05-16-2010, 07:12 AM
Just saw this ad in Elektor.
This thing uses standard VGA monitors.
Has to have a nice video processor on board.
It's the kind of thing that would be nice as an add on
for vga monitors...to let a nice display be created
by a controller. I wonder just what their vga circuitry
consists of in that box.
http://lookpic.com/d2/i2/2161/mbWDxgkz.jpeg

potatohead
05-16-2010, 07:49 AM
@Heater, I'm not sure we are talking about the same port.

http://www.youtube.com/watch?v=vi5S1aYio_U

That is the real arcade code, running what it thinks is a vector display, not the older chunk-o-roids one from long ago. http://www.youtube.com/watch?v=vxGRBhPJLek&feature=related

Still, your point is valid. A real vector display actually draws vectors...

I was impressed by the quality of the port, and that the vector to raster conversion could be done on a 1.7Mhz machine at playable speed.

:)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
8x8 color 80 Column NTSC Text Object (http://obex.parallax.com/objects/550/)
Safety Tip: Life is as good as YOU think it is!

Phil Pilgrim (PhiPi)
05-16-2010, 08:36 AM
The trouble, of course, with a true, real-time analog vector display (as opposed to an analog storage tube display) is flicker. The more stuff you have on the screen, the more pronounced the flicker becomes. In school, I had access to a PDP-7 with a vector display, which we commandeered occasionally for playing Spacewar!. With the few, short vectors required for that game, the display was comfortable enough to watch. But for more complicated images, the flicker could be very annoying. The brightness level would also diminish as the amount of stuff on the screen increased.

-Phil

Rayman
05-16-2010, 10:57 AM
I don't know what kind of graphics you are trying to show, but here's one trick I did before to show oscilloscope-like data in high resolution on XGA:
http://ftp.parallax.com/forums/default.aspx?f=25&p=1&m=295413

Had to do it in the vertical direction, but could use a cog to plot a graph (two cogs for 2 graphs).



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm

potatohead
05-16-2010, 11:33 AM
Doesn't the flicker depend on the scan rate?

The old Asteroids game had a fairly high persistence display, and the CPU was slow. Subsequent ones had faster displays and rendered a large number of vectors without annoying flicker. Most of the time, it was difficult to even see flicker during peak times.

If all the vectors can be drawn at, say 60 - 100Hz, there isn't going to be an issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
8x8 color 80 Column NTSC Text Object (http://obex.parallax.com/objects/550/)
Safety Tip: Life is as good as YOU think it is!

Phil Pilgrim (PhiPi)
05-16-2010, 01:17 PM
Phosphor persistence is the enemy of lightpen accuracy, so there's a tradeoff. The PDP-7's interactivity relied heavily on lightpen input, so screen persistence could not be too long. Flicker and loss of overall intensity also depend on the total length of the vectors, not just their number. A few short-vectord sprites in a video game aren't going to affect flicker that much. But a 3D mesh model certainly will.

But we're getting off-topic with analog display reminiscing...

-Phil

heater
05-16-2010, 02:16 PM
@potatohead: "I'm not sure we are talking about the same port." I'm not sure we are talking about the same port:)

That may well be the original code driving what it thinks is a vector display which ends up being a raster display. And as I said it ends up looking like a chunky low res raster display instead of the high res vector original.

Compare to the screen shot of the original vector graphics on wikipdia.en.wikipedia.org/wiki/File:Asteroi1.png (http://en.wikipedia.org/wiki/File:Asteroi1.png) see how smooth that is.

I don't remember flicker being a problem. Of course it would be if trying to draw a lot of objects.

I used to write code for the vector graphics of those huge old round radar displays. It was amazing how much we could get on the screen, targets, range rings, maps, text etc. Of course in radar there is a big cheat because you rely on a long persistence phosphor and you are only drawing targets that are in the vicinity of the radar beam direction at the time.

It was not until raster displays could get up to something like 2048 * 2048 that they started approach the quality of the vector displays and took over.

Now it just so happens I have a radar tube from 1947 or so. It looks like this www.tubecollector.org/vcr97.htm (http://www.tubecollector.org/vcr97.htm) I often wonder if the analog capabilities of the Prop could generate a vector graphic on that.

I just have to find a way to generate the 2000v required to light it up:)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

potatohead
05-16-2010, 02:44 PM
Got it. I totally agree then. I really like vector displays. The Asteroids was 1024x1024 vector space. I've toyed with drawing on my scope... Saw the raster display on Hack a Day, and it's just been sitting there teasing me. A real vector display term would be damn cool.

Nice tube. You really should light it up one day.

Edit: If you ever choose to run that game under MAME, do it on an old SGI. Those ran 1280x1024, but featured very nice line anti-aliasing, that looked essentially true to the original.

@Holly, wonder if that isn't some Matrox type 2D display chip? Their 2D stuff is excellent. Fast, both electrically for sharp pixels and graphically with good support for a wide range of 2D primitives. Cheap these days too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
8x8 color 80 Column NTSC Text Object (http://obex.parallax.com/objects/550/)
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 5/16/2010 6:51:59 AM GMT

Bill Henning
05-16-2010, 09:30 PM
I did, thanks - your turn to check your email :)


Jacob D said...
Thanks all for the replies. I guess I am still asking too much of a single Propeller. Bill - Check your email.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com (http://www.mikronauts.com) E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus (http://mikronauts.com/products/morpheus/) / Mem+ (http://mikronauts.com/products/morpheus/memplus/) / PropCade (http://forums.parallax.com/showthread.php?p=894725) / FlexMem (http://forums.parallax.com/showthread.php?p=894853) / VMCOG (http://forums.parallax.com/showthread.php?p=878382) / Propteus (http://mikronauts.com/products/propteus/) / Proteus (http://mikronauts.com/products/proteus/) / SerPlug (http://mikronauts.com/products/serplug/)
and 6.250MHz Crystals to run Propellers at 100MHz (http://mikronauts.com/products/mikronauts-625mhz-crystal/) & 5.0" OEM TFT VGA LCD modules (http://forums.parallax.com/showthread.php?p=852195)
Las (http://mikronauts.com/software-products/largos/) - Large model assembler Largos (http://mikronauts.com/software-products/largos/) - upcoming nano operating system