Newbie here - Trying to learn how to do graphics and colors on a tv
BillDer
Posts: 33
Hello,
I am very new at this and learning as I go. I have taken the graphics demo supplied on the CD and I would like to change the colors of the numbers that count up on the screen. I've noticed that the colors change depending on where they are on the screen. That was a big revelation that I didn't expect. My question is why is that? Also, how can I control the colors so that I can programatically change them to any of the colors that are displayed on the graphics palette program?
I realize how little I know on this and would also appreciated learning more on how all this graphics stuff work.
Ultimately, my project will use one of those projectors and display the propellers graphics on a huge screen. The display will show the results of the interaction with the sensors that kids will play with.
Any and all help would be greatly appreciated. This is the last hurdle (other than moving it from the proto board to a more permanent box).
Thanks
Bill
I am very new at this and learning as I go. I have taken the graphics demo supplied on the CD and I would like to change the colors of the numbers that count up on the screen. I've noticed that the colors change depending on where they are on the screen. That was a big revelation that I didn't expect. My question is why is that? Also, how can I control the colors so that I can programatically change them to any of the colors that are displayed on the graphics palette program?
I realize how little I know on this and would also appreciated learning more on how all this graphics stuff work.
Ultimately, my project will use one of those projectors and display the propellers graphics on a huge screen. The display will show the results of the interaction with the sensors that kids will play with.
Any and all help would be greatly appreciated. This is the last hurdle (other than moving it from the proto board to a more permanent box).
Thanks
Bill
Comments
Believe it or not this is a common question here.. [noparse]:)[/noparse] I'm sorting through some of the older
threads as there has been great information posted, but it's a little buried in this forum software.
I'll post a couple links as soon as I find what I'm hunting for.
You should also consider picking up a copy of the Hydra book. It explains video in full detail,
a good addition to any Propeller users library.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
http://www.parallax.com/dl/docs/prod/prop/Hydra-Ch16Sample-v1.0.pdf
In plain english, this is how it works:
There is the screen buffer array that contains actual graphics pixels. This is arranged as tiles, standing 16 pixels wide, two bits of color per pixel, and 32 pixels tall. The default configration of the graphics driver is to line these tiles up in the HUB memory such that they form a full screen bitmap. The plot, line, circle routines all work assuming this is the case.
There is an array of HUB memory addresses, and this is the tiles array, and it determines which of the tiles points to which area of the HUB memory. A tile is one long wide, and 32 longs high. Tiles are arranged so the memory addresses start from the upper left, going down 32 pixels, then moving one tile over, going down 32 pixels, etc... until you reach the last memory address, which is the bottom of a tile in the lower right.
Another array is the colors array. For each tile, you can choose what colors you want it to use! Here's the tricky part. There are 64 sets of colors possible to define. You define those in the colors array. In the tiles array, you choose which of those color sets you want to use.
There are 4 colors possible with this driver. Color 0 is background, with the other three being foreground.
The reason why the pixel color changes depending on where you are on screen is because that particular color has been defined as different for each row of tiles! It does not have to be this way, depending on how you deal with the tiles and colors arrays.
That, plus the info in the sample, will get you to picking whatever color you want to pick for the tiles.
Have fun!
Edit: The tiles might be 16 pixels high too! Depends on the driver settings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
http://forums.parallax.com/showthread.php?p=780904
Mike Green did a good tutorial on graphics a month or so back, that's another one
I'm hunting down if someone can lay their hand on it first.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
http://www.rayslogic.com/propeller/Programming/GraphicsDemo.htm
Bill
I read through the suggested topics above. I am now beginning to understand a little bit.
My question is on the following code from the demo:
'init colors
repeat i from 0 to 63
colors := $00001010 * (i+4) & $F + $2B060C02
'init tile screen
repeat dx from 0 to tv_hc - 1
repeat dy from 0 to tv_vc - 1
screen[noparse][[/noparse]dy * tv_hc + dx] := display_base >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)
In init colors above, I don't understand the formula entirely. But what I think it is doing is automatically setting up some colors.
It is in init tile screen where I am still really confused.
I think I understand what the two repeats are doing. They are indexing the tiles for the screen and assigning something unique to them..... But what is it assigning? I really don't understand. Can someone help explain it?
Thanks in advance.
Each long in the colors array represents 4 color values, for colors 0, 1, 2, 3. They are referenced by number in the tiles array, one for each color combination defined. There can be 64 combinations.
The init tile screen is writing the addresses each tile will get it's pixel data from, and selecting one of the 64 possible palettes.
Each tile is being defined with addresses that go sequentally in HUB memory to form a screen buffer. The upper left tile is the first tile, and the top scanline of it, is the first bits of screen memory. From there it fills downward, until the end of the tile is reached, then the next tile over gets the next address.
Each tile points at a little bit of HUB memory.
Also mixed in there are the color palette entries for each tile!
Because of this, addresses must like on a 64 byte boundary. In the tiles array, each word in there encodes the screen address for the tile, and the color palette in use for it. 10 bits for the address, and 6 bits for the color palette entry that will apply to that tile.
For what it's worth, if you work through this, you are on your way!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 2/13/2009 4:52:26 AM GMT
I guess my question is more fundamental. Looking at the code that sets up the tiles (copied at the bottom).
I can't figure it out. I know that the screen array is getting loaded with pointers and from what everyone is saying, also the color set for the tile.
But in looking at the line below, how is this being done? I know that display_base is the starting address $5000. But why is it shifted right by 6 bits? ">>6" and why then is dx*tv_vc then added to ((dy & $3F) << 10) and this is shifted 10 bits to the right?
And where in this is the color set 6 bits?
I think if I can figure this out it will help me not only with this, but in my other programming projects.
I also don't understand what is going on in the color array. I know what it is doing, loading all the color sets possible. But what is going on with in the code, Why is $00001010 being multiplied by (i+4)? And then anded to this => & $F + $2B060C02
So far I can't figure this out either.
Thanks in advance.
screen[noparse][[/noparse]dy * tv_hc + dx] := display_base >> 6 + dy + dx * tv_vc + screen[noparse][[/noparse]dy * tv_hc + dx] := display_base >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)
Tile addresses are 6 bit aligned in memory. This was done to save bits in memory by doubling up the addressing and the color. Also, it makes the assembly language driver part easy.
I'm hammered with work at the moment. I'll break this down for you later, when I've got some Prop time coming to me!!
Look for something here in the next day.
You are right too. Get through this, and it's a big step. Lots of things get easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
In the setup colors line: colors[noparse][[/noparse] i ] := $00001010 * (i+4) & $F + $2B060C02
The index i, is being used to generate the rainbow color, as well as setting the standard colors. It's encoded the way it is, just for brevity.
Each element of the colors array, contains four bytes. Each of these is the color value for the 4 colors. Binary 00, 01, 10, 11.
In the statement above, a set of rainbow colors, chosen mathematically is added to a base set of colors that is the same for all the tiles. When working with bit fields like this, where multiple values are encoded together, it's often easy to calculate them, then mask them, then add them together.
colors[noparse][[/noparse] i ] := $00001010 * (i+4) & f
The result of this will be added to $2B060C02, which is the base colors that are constant for the tiles.
Another way to think of this looks like this:
Let's say our colors are shades of grey: 03, 04, 05, 06. We want to put them into the colors[noparse][[/noparse] i ] array. Since the colors[noparse][[/noparse] i ] array is really just a 32 bit number, it's necessary to get the color values desired into the right position.
colors[noparse][[/noparse] i ] := $03 + ($04 * $ff) + ($05 * $ffff) + ($06 * $FFFFFF)
-or-
colors[noparse][[/noparse] i ] := $03 + ($04 << 8) + ($05 << 16) + (16 << 24)
The "+" sign is really an OR operation when used this way.
However they are defined, each of the colors array elements represents a set of four colors that will apply to whatever tile references them.
If you want to, you can just set your colors in a simpler fashion, by eliminating the first bit, and just set all the colors array elements to the same value. Or, you could setup colors in a DAT section and assign them to the colors array as you see fit.
All that happens here is a set of color values are put into memory for use by the tiles. Depending on what you want to do with colors, you might choose to define fewer colors array elements, and point multiple tiles to the same sets of colors.
'init tile screen repeat dx from 0 to tv_hc - 1 repeat dy from 0 to tv_vc - 1 screen[noparse][[/noparse]dy * tv_hc + dx] := display_base >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)Here the tile screen memory addresses are setup, along with the tile color references back to the colors array. Both are happening at the same time. And this works just like colors does, in that multiple values are encoded into the same number, as a bit field.
That bit field is:
CCCC CCTT TTTT TTTT
The lower 10 bits form the base address of the tile. The upper 6 bits form the index into the colors array, where each tile gets it's colors from. Each tile then can point to some place in the Propeller address space, and have it's own set of colors, defined in the colors array.
Display_base is shifted right, so that it's aligned on a 64 byte boundary and so it fits into the space alloted by the assembly language TV driver. The rest of it there is simply laying out sequential addresses, based on the number of the tile, plus the shifted display_base address. These are stored in the tiles array, one entry for each of the tiles that forms the screen.
(DY & $3F) << 10 is a quick way to specify that tiles get assigned colors based on their vertical position. (DY & $3F) It gets shifted right, for the same reason colors get shifted; namely, so that the value is properly aligned in the bit field. If this is not done, then color array indexes end up being encoded as addresses, and that will generally result in either nothing, or garbage being rendered on the screen!
A good exercise is to get the driver up and running, then add a bit of code, right after 'init tile screen and before 'init bouncing lines.
Here you can make a secondary statement and focus on just one tile!
Say it's tile number 4. That's 4 tiles in from the upper right of the screen. Since a tile is 16 pixels wide, and 16 pixels tall, tile number 4 is in charge of horizontal pixels 49 to 63, and vertical rows 0 to 15.
Let's say we define colors[noparse][[/noparse]60] := $02030405
To change the color definition of tile 4:
This takes whatever the current definition of tile 4 is, masks off the color info, takes the new color info, shifts it into position, then adds the two together, finally storing it in the tile definition to define colors for tile number 4!
The '%' is binary notation. I did that so you could visulalize the bit field. Doing a logical 'and' with something, and the value 0, means it will always be zero. That's called masking. The masking was necessary, so that adding the shifted color array index would actually result in that index, not some combination of whatever was in there, and the index!
From here, it's possible to twiddle with the tiles and colors and find your way around, just like I did, when I ran this program.
There are easier ways to do this stuff. However, this driver provides a LOT of capability in a very small amount of code. That is what makes it hard. If you can make your way around this program, you are well on your way to doing well on the Propeller.
Hope this helps!!
(and if I've bone headed this, and you catch it --congrats!! Tell me all about it! If not, may others here help me out!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 2/15/2009 8:46:16 AM GMT
I just printed this off and have worked through this! I think I get it.
This was extremely helpful. The fog was lifted.
Question:
Looking at the color array alternative calculation you mention above, should the last element (16<< 24) be (06 << 24) instead for this example? Or am I missing something?
colors[noparse][[/noparse] i ] := $03 + ($04 << 8) + ($05 << 16) + (16 << 24)
Yes, it's a typo [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!