TV terminal/ Graphics colors?
Ravenkallen
Posts: 1,057
I love using the Prop attached to a TV and i am starting to get to know the various objects that make it possible. So far i have only one question. It is probably really obvious, but the answer has eluded me for to long. How do you make more than just a few colors available in the TV_terminal object(like when you enter in a number that corresponds to the color) ? Same thing with the Graphics object?
It looks like you can only have 3 colors or something? I know there can't be that few, because how did the creator of the Graphics palette demo get all of those colors? I have looked over the various objects trying to understand the lower level coding, but i can't figure out how to get more blasted colors....Any help would appreciated!!!!
It looks like you can only have 3 colors or something? I know there can't be that few, because how did the creator of the Graphics palette demo get all of those colors? I have looked over the various objects trying to understand the lower level coding, but i can't figure out how to get more blasted colors....Any help would appreciated!!!!
Comments
I am having the same question - I was trying to figure it out earlier today. Potatohead explained palettes and tiles to me at UPEW, but I waited too long to experiment with it and have since lost the benefits of his generous wisdom. Have you studied the Hydra manual? I don't have a copy yet, but am thinking that it might include the graphics info that we need.
Check out the "similar threads" below. They look promising.
Lev
http://www.parallax.com/Store/Books/Propeller/tabid/171/CategoryID/45/List/0/SortField/0/Level/a/ProductID/474/Default.aspx
Lev
Well, after doing battle with pots today, I'm open for this. Here's the thing:
When you run the Parallax graphics drivers, the colors are stored in a colors array, which is 64 longs. There are 4 colors per entry in that array, numbered 0 through 3, from least significant byte to most significant byte.
Now, the screen you see, is composed of a list of tile addresses. Each word in the screen array contains 6 bits to index the colors array, so the colors for that particular tile are known, and it contains 10 bits to point to some location in the HUB for the pixel data, so the pixels in that particular tile are known.
For any tile, there are only 4 colors. Each tile can have a set of colors, with that set being contained in one of the longs in the colors array. Which set, depends on the value contained in the 6 bits found in the screen array.
A bitmap display is simply a sequentially addressed series of tiles! Because some of the bits are used for the color specification, screen tiles must be 64 byte aligned in the hub, and that's exactly what the default use of the driver does, stacking them one after the other in the HUB memory.
On a side note, the graphics cog knows this, and is built to operate with the tiles and addresses setup by the TV driver.
I'm gonna go and get my signature updated, so the commented graphics_demo.spin can be found.
http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin
The big problem with that demo is the color and screen init code is mixed together some, and lots of short cuts and bit operators were used at the same time. Takes a while for the average person to parse it.
Read through the commented one, and the supplied methods for assigning colors and tiles. The color scheme is changed to a simple 4 color per screen one, then some examples of assigning colors per tile are done in slo-mo, to help make it click.
The additional methods can be used with the graphics_demo, or that program can be used as a template itself, as it's not really changed from the Parallax one.
Back to graphics 'n colors in general.
Thanks for the refresher! I greatly enjoyed talking with you after hours at UPEW. What do you recommend for a structured, hands-on way to practice and experiment with the concepts you describe? BTW, I still have your commented version of Chips graphics driver, which is helpful for understanding what the code is doing.
@Rav
I hope I am not hijacking your thread. I think we are asking the same questions.
Lev
Get a driver running on the board, using whatever default "demo" type display it has.
Go through and attempt to comment the code. Where writing a comment isn't possible, that's a thing to know.
Modify things, one at a time, to see what happens. If nothing happens, FLAG that, because it's significant, in that it will bite you later on, or is subtle; otherwise observe the behavior.
For graphics drivers, there is the screen addressing. It's good to just write values to the screen, using byte[screen][offset] := value, where value is some known color. I like to use the monochrome ones for this, which means 02-07. Edit: I've been working on raw video stuff too long. For this driver, you can write anything to the screen. It will just be pixels. For colors, and testing of things that could generate colors, I like the monochrome ones. Easy to remember, easy to see.
No matter what it is, simple bitmap, tiles, sprites, etc... is good to know where the source pixel data is, and to know something about that data. Usually, it's 1, 2, 4, 8 bits per pixel, and on Propellers not all values equate to colors, so be careful about that. (00 and 01) are known sync values, BTW. Don't ever use them.
Colors is the same way. Try to establish the link from the color pixel seen on the screen, back to it's source definition in the code. That's what you are changing things to try and do.
Once you have a handle on those basic things, I would then explore the screen geometry. Where is the origin? How do pixels map to screen coordinates? Some test dots, placed here and there, can reveal that, as can reviewing the code.
From there, you need a goal.
Drawing a clock face, or building up some test patterns, you know blocks, lines, and other things needed to see monitor performance is a great idea, and doing that doesn't require much in the way of understanding. Simple lines, and blocks can be done with just a dot plotter.
On that note, once you've sorted out how the data looks, and it's addressing, a dot plotter is a great thing to write. Given X and Y, how to light up one single pixel, and have it be the colors it can be?
If that doesn't make a lot of sense, then it's going to have to be some general graphics information. Honestly, I don't know of a solid reference that just covers graphics in the abstract. I tend to enjoy older references, having come up on computers during the early 8 bit times. Those were fun times, because the graphics systems were limited enough, and new enough to warrant basic coverage of things like pixels, tiles, colors, scan lines, memory addressing, dot, line, etc...
Maybe somebody else has some ideas on references, tutorials and such. For me personally, I find it useful to look up the definitions of things, and look at older graphics systems, as those are best aligned with what the Propeller does today. Some advanced techniques are in use on it, and these perform very well, because of the parallel nature of the chip. That's kind of a fun area, but difficult if one is not thinking about games.
In the HYDRA book, the Parallax driver is given a good treatment. Not a bad place to start. It's also a good idea to go and find some other graphics done with the Parallax driver and explore those.
@Lev...Yes, we are talking about the same thing(I think).
Honestly, I've been thinking about basic graphics. All the really cool concepts, currently in use on the Prop, were all pioneered in the late 80's, maybe early 90's.
They were known before then, most of them, but really were shown off on those early computers, where it was possible for ordinary people to just go and do stuff. That's the early era of video games, and it's a really fun era.
Tearing down games is a good activity. On the Propeller, we've got some great examples, and there is source!! The value of this cannot be understated.
I think it's hard right now too. For people, who didn't follow these things, many of the references are in pieces, or make a lot of assumptions about basic things. Spent a little time looking online, and most all the great references I enjoyed, and honestly will still learn from, are online, but the context is old computers... That's a bummer really.
The real fun of the Prop, on graphics, is that basic, simple techniques are well aligned with it, and the thing is fast enough to really get something out of it. Back then, it was everything a person could do to get visuals that were compelling. Props are kind of easy because of the speed.
Because they are multi-processors, all kinds of intriguing things can happen, and has. That's the harder part, because many of the old ideas apply, but with really interesting new twists. IMHO, something could be written about all of that and do a lot of good.
Finally, don't underestimate the Parallax driver. There are more sexy ones that zero in on specific purposes, games, text, etc... But this driver is capable of a lot, and it's not really been shown off much. (some buffering techniques with the tiles, and color indirection are two I can think of that are way under used --another day)
http://www.rayslogic.com/propeller/Programming/GraphicsDemo.htm
http://www.rayslogic.com/propeller/Programming/TV_Colors.htm
Now, assuming you are using a Demoboard style VGA interface (8 pins to 8 resistors to 5 outputs RGBHV), the bits in each color byte are RrGgBbHV. So $0C translates to R=0,G=0,B=3,H=0,V=0 (bright blue) and $F0 translates to R=3,G=3,B=0,H=0,V=0 (bright yellow).
The reason there are two longs and why each color is repeated twice in each long has to do with how characters are stored in ROM. Each character is 16 pixels across. But rather than storing them as a sequence of words, two characters (odd and even) are combined into a single long with the even character using the even bits and the odd character using the odd bits.
Thus if you want to print out an even character the first palette long is used. So if the even bit is set, color 1 or 3 are output, but if the even bit is cleared, color 0 or 2 is output. For an odd character the second palette long is used and an odd bit set outputs color 2 or 3 and an odd bit clear outputs color 0 or 1.