"Real Time" High Resolution Vector Graphics
Jacob D
Posts: 8
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 
, 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)
, 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 . 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 (
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
, 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), 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 . 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 (
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
Comments
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/
-Phil
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 [noparse]:)[/noparse]
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 5/15/2010 5:50:41 PM GMT
it had one display driver, and two cogs doing the run length decoding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
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.
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 [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
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
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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.
That is the real arcade code, running what it thinks is a vector display, not the older chunk-o-roids one from long ago.
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.
[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
-Phil
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
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!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
But we're getting off-topic with analog display reminiscing...
-Phil
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 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 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[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 5/16/2010 6:51:59 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system