need help with simple graphics samples (from HYDRA book)

gonzobrains

Can anyone give me details as to what exactly is going on here? Not from a syntax perspective but what the actual values are and what is being done with them.

Thanks,
Jeff

'init colors
repeat i from 0 to 64
colors := $00001010 * (i+4) & $F + $FB060C02

'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] := onscreen_buffer >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)

FredBlais

For the init color section, it is for the·initialisation of the color palette on the tiles of the screen, this is why on some demos, you see that color are changing when the height is changing, try plotting some pixel (preferably big ones width:15)·with color 1 on the screen.
·

gonzobrains

Yes, but could you explain the individual values as to what they mean?

potatohead

We've had threads on this before, but I'm having trouble finding them.


***repeat i from 0 to 64

This is the color palette array. It contains 64 longs. Each of the longs contains byte sized color values for the colors 0, 1, 2, 3 So then, the values 0 and 64 reference the boundaries of that array.


****colors := $00001010 * (i+4) & $F + $FB060C02

This is always an area where people have trouble. Imagine each of the colors array longs filled with color values. For grey scale stuff, that would look like this:

00 := $03_04_05_06 the underscore is an acceptable number delimiter, the "$" means hex values.
01 := $07_06_05_04
.
.
.

If you were to put all the color settings used in the graphics demo into a DAT section, they would consume a lot of space. Looking at the example greys I did above, tells the story there, as a bunch of longs would have to be defined to be read, or used as the colors array.

Rather than do that, math was used to obtain a suitable set of colors.

$00001010 * (i+4) & $F + $FB060C02

So this boils down to evaluating this expression for each value of i. When you do that, you end up with the 32 bit value that is stored in the colors array. It's the same colors, but for the rainbow one used for the numbers and such. Substitute i and solve this for a few values. "&" means logical "and". Pop it into excel, if you want to, and see what the actual colors array values are.

In a nut-shell, this is really just about filling that array with a known set of colors with very little code.

Now, on to the tiles! With this graphics driver, the screen is divided into tiles, each 16 pixels wide, and I believe 32 pixels high. Each tile references one of the color palette array values, meaning there are 64 color combinations avaliable for each tile. What colors actually appear depends on the color index present in the tile, the tile pointer to the colors array, and the value contained there.

Color 00, 01, 10, 11 are the 4 possible colors. Tiles are built in this program such that they are two bits per color.


***repeat dx from 0 to tv_hc - 1
****repeat dy from 0 to tv_vc - 1
****screen[noparse][[/noparse]dy * tv_hc + dx] := onscreen_buffer >> 6 + dy + dx * tv_vc + ((dy & $3F) << 10)

This is more math to define the tile screen addresses with not much code. tv_hc and tv_vc are the number of tiles values, horizontal and vertical.

For each screen position, the address in HUB memory, where that tile pixel data exists, is defined in the screen array, which is just a list of tile addresses.

Looking at screen[noparse][[/noparse]dy * tv_hc + dx] we see that a simple multiplication and addition index a given tile. Tiles are arranged horizontally, one after the other, until the end of the screen is reached, filling down, row by row, until the bottom of the screen is reached. Tiles start at upper left and end lower right.

0,1,2,3,4,5,6
7,8,9,A,B,C,D
.
.
.

The onscreen_buffer is the area of HUB memory visible on the screen. Let's call it the start of the graphics screen. Tile addresses, after being computed, are added to this, and put into the screen array.

The rest of the math on that line is about computing a tile address. Each tile is 64 bytes long, or 128 --I'm not at a prop to check! In any case, tiles are 16 pixels across, 2 bits per pixel for a total of one long per row. Tiles being 32 rows deep (either that or 16), means a total of 64 or 128 bytes per tile.

If we are looking at the very first tile, it's start address is literally visible_buffer. If we take the next one over, it's visible_buffer + (tile position in the x * 64). The next one is the same visible_buffer + (tile position in the x * 64)

If we are looking at the very first vertical tile, right below the one in the very upper left corner, it's address is visible_buffer + (number of tiles per row * 64 + tile position in the x).

That's what the math on the rest of the line does.

only 10 bits of a tile address are significant. The rest of the bits are the index into the color array.

To change a color in a tile, you need to look at the screen array to get the address of the tile, mask off all but the color bits (lower ones, I think), then use that value as an index into the colors array, then change the long you find there. All pixels, with that color value (0-3), within that particular tile will then take on the new value.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!

potatohead

This is all explained fairly well in the sample HYDRA book chapters you can find online here, and in the HYDRA book.

You can find those on the HYDRA product page.

There is an error in those where the tile addressing runs vertically, from upper left to lower right. It's horizontally, from upper left to lower right. Everything else is good.

http://www.parallax.com/Store/Microcontrollers/PropellerProgrammingKits/tabid/144/CategoryID/20/List/0/SortField/0/Level/a/ProductID/467/Default.aspx

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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!