TV object color limitations
Lord Steve
Posts: 206
Is it possible to overcome the 4-colors-per-16-pixels limitations of the TV object?
·
·
Comments
Try this thread: http://forums.parallax.com/showthread.php?p=654928
Post Edited (Mike Green) : 3/20/2008 2:36:14 AM GMT
What is your target display like?
Brute force works quick and easy, with any pixel being any color, but it eats a lot of RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
However the higher the resolution, the more memory will be consumed
by the driver. It's a trade off..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
A Living Propeller FAQ - The Propeller Wiki
(Got the Knowledge? Got a Moment? Add something today!)
Problem with NTSC is it just isn't square to begin with. Vertically, you either do one scan line, or two, or three, etc... Otherwise you get very odd looking displays.
The safe area lies at about 192 pixels. Could be 200 with no significant issues, I think. A small change to the driver would handle that. Gotta just add a few scan lines to the active display area.
Vertically then, it's really 192, 96 --or-- 200., 100. kind of a cut and dried piece.
Horizontally, that driver uses static color timing. It's a one to one relationship between the NTSC colorburst and pixels. Anything above 160 will deliver artifacts, unless two pixels are drawn next to one another. Effective color resolution then is 160 pixels or less. If you drive it higher, and make sure pixels are doubled up, you can position things on the display with greater than 160 pixels of precision.
Your lowest resolution then is the best overall fit, mostly because of RAM. Try it there.
That driver does not do color boundary checking in the COG. If you look at the SPIN program, there is a color lookup table in there (CLUT). That's a mapping between normalized colors eg: 0 = black, and the native propeller colors eg: 2 = black. Just be sure you use that, and the display will be ok.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
I don't have the color-conversion worked out, yet but I do have the viewer working.
Currently it will read a stripped-down .xpm graphics file from SD.
Plenty of colors... just not the right colors.. *yet* But at least you'll see that
more is possible.
A quick & dirty demo is attached. Put "balloon.xpm" on your SD and run.
(The image was reduced to 64 colors, then saved as .xpm using gimp.)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
A Living Propeller FAQ - The Propeller Wiki
(Got the Knowledge? Got a Moment? Add something today!)
I have looked at this and think I might like a 160x96 or 320 x192 resolution.· Nice work!
1) If each pixel is a byte, how can there be ~400 possible colors?· The CLUT is also byte entries, is it not?
2) Does anyone have a color conversion formula to go from RGB to this object's format?
3) Or, alternatively, does anyone have a 256-color palette (or image with a palette) that corresponds to this object's CLUT?
I've been working on an RGB to CLUT conversion for this.
Used in spudview http://forums.parallax.com/showthread.php?p=717832
The table is not perfect, and still a little bulky, but functional.
It's based loosely on websafe colors.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
A Living Propeller FAQ - The Propeller Wiki
(Got the Knowledge? Got a Moment? Add something today!)
At resolutions beyond 160 pixels horizontally, that driver will generate pixel / color artifacts. That's due to it using the simple color timing, non-interlaced. One complete color cycle takes the same amount of time as the 160 pixel sized pixels do. That's a 1:1 relationship. Smaller = no artifacts, larger = more color.
So, plotting an even 320 pixel pixel, say it's just a monochrome one, will render on the TV as a colored one. An odd pixel will render as a differently colored one. And just with monochrome pixels, you can get a batch of colors by having a play with plotting them different places. The old Apple ][noparse][[/noparse] was all about this for it's color graphics.
At resolutions of 160 or below, none of that applies. So that's one byte per pixel, and we can see every pixel as a distinct pixel. The propeller video hardware will generate the little sub-pixels necessary for color graphics for us, giving that pixel color. There are 16 of those, for a total of 16 base hues. If you look at the wiki, those are shown across the bottom, and up the right side. (forgot some at first, so I just drew them in as an afterthought.)
Additionally, there are 5 safe intensities, so that adds up to 86 or so colors that are in spec and that will absolutely display anywhere on anything. If one pushes it, the full compliment of standard colors (non-artifacted ones) is 130 or so. See the wiki for the exact number. I pushed it for the screenie posted on the wiki, just because my capture card didn't seem to mind the over driving of things, and it was handy to have everything up in one image.
That's the longer story of why one byte does not deliver 256 colors. Not all the values will display on the TV as some of them are used for sync signals. To the Propeller, everything is just colors and timing. The entire frame is just drawn to the screen, sync and all. That's also why there is a CLUT in that demo. The value zero, is not black, but blacker than black and should only be a signal, not something in the display frame.
At resolutions above 160 pixels, the artifacting comes into play. At 320 pixels specifically, two ordinary pixels fit where one normally would. This consumes two bytes instead of one! For the Propeller, that's a lotta RAM, so the pixels are tall, to fit everything in. I think that one runs at 320x96 to generate the 400 color display. 320x192 is about 61K of RAM. Too much to fit on chip. 320x96 is 30K or so, leaving just enough for the little SPIN demo to draw the colors.
The reality is more than 400 colors, because the standard ones are not all represented in the colored squares at upper middle of the screenie attached to the wiki. Additionally, not all the possible color combinations were drawn. 512 colors is a reasonable expectation for that particular method of delivering video. I don't think I used the high-saturation colors possible in the standard set for any of the mixing.
What happens is the TV still does 160 pixels of color resolution, but the overclocking of the pixel rate puts two color signals where there would normally be one and that's the source of the additional colors seen. This is an NTSC thing for sure. I don't think PAL does artifacting the same way.
(maybe somebody else here knows)
To do anything of significance, other than plot screens, at the 320x96 resolution would mean building tile or sprite drivers so that the amount of RAM required to fill the screen is less. That's not a big deal, as that driver can easily do tiles, but has not yet been done. The tiles and or sprites are mandatory at 320x192 and above.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net