Graphics, Tiles, and Colors

joshrl

Just getting started with the Propeller and fooling around with the graphics demo. I think I have a rough idea of what tiles are and how they are made up of a 4-color palette and a 16x16 pixel data structure. A pixel in the stucture is repesented by a 2-bit number that references the index of the color in the palette for the containing tile, right so far?

I also think I have a grasp on how the colors array works. Each index in the colors array represents 4 colors (maybe the variable should be called colorsets, just a thought). Each tile references an index in the colors array (a 6-bit number...0 to 63) that defines the colors that are available to that 16x16 pixel tile. Still right?

My question is how do the tiles color palettes get set? I think it happens in this code:

  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)

Can anyone explain what is happening here?

BTW, very impressed so far with the propeller -- it sort of blows my mind.

Thanks,

Josh

Mike Green

The screen buffer is an array of 16 bit words that correspond to the tiles. Each tile points to an area of memory (display_base >> 6 + dy + dx * tv_vc) that contains its pixels and points to an entry in the color palette table ((dy & $3F) << 10) for the tile. Each tile requires 16 longs (64 bytes) in the pixel buffer and a long in the color table.

Jim Fouch

Josh,

Check out my post. It should help make it easier.

http://forums.parallax.com/showthread.php?p=605448

Jim

joshrl

Thanks, that is helpful -- it still seems a little fuzzy but good enough to get into some trouble.

Ym2413a

joshrl said...

(maybe the variable should be called colorsets, just a thought)

Normally it's called a CLUT. Color Look Up Table, in computer graphics.
The 16x16 tiles are 64 bytes in size each aka 16 longs. Each long is one tile line from left to right.
The TV object needs all tile data to be aligned in HUB ram by every 16 longs.

Yes the Propeller is a mind blowing chip! ^^

Dennis Ferron

Josh, I had a hard time understanding it too. Mike explained it to me in a reply to one of my forum posts, and it was a good explanation yet I couldn't get myself to understand a bloody word of it. (No offense Mike - the communication problem was on my end.) It wasn't until I was in the middle of a shower 24 hours later that I suddenly "got" it. (I barely stopped short of running out of the bathroom naked shouting "Eureka" like Archimedes, but I did shout. Luckily my friends are used to strange behavior from me.)

I think the confusion results from a few unusual things about the way the graphics are laid out in memory (i.e., optimizations). One is that it would seem that for each tile, the 16-bit pointer to the tile's bitmap and the 6-bit palette index for the tile are both packed into the same 16-bit tile table entry. (By shifting out the 6 least significant bits of the tile bitmap pointer.)

So if you put a set of four colors into, say, palette entry 2, you'll also have to put a "2" into the upper 6 bits of the tiles you want to use those colors, otherwise they won't show up anywhere. Originally, I had thought that since there were 64 palette table entries in the graphics demo, that meant that there would be one palette table entry for every tile on the screen. I was having problems because I expected that changing the palette table in position 0 would change tile [noparse][[/noparse]0, 0], changing the 19th palette table entry would change tile [noparse][[/noparse]1, 2], and so forth. This is apparently NOT how it works. Instead, the upper 6 bits of a tile table entry determine its palette table entry to use, and there is not necessarily any correlation between palette numbers chosen and tile x,y coords. Do I have that right?

Another thing that was throwing me off was that I have done CGA graphics drivers in assembly and for that, the graphics memory is laid out line by line. (The lines are also interleaved in memory, but that is irrelevant to my point.) Anyhow, so I would have expected the first line of the first tile to be in the buffer, followed by the first line of the next tile, and so forth, until it gets to the end of the screen, in which it should start with the second line of each tile, and so forth. NOT true.

Instead, I believe the tiles are laid out in memory one after another. This makes sense for having a tile system but seems weird if you were expecting a plain buffer. So for instance if you were going to draw a line of pixels all the way across the 0th line of the TV screen, rather than write to memory in one long line, you would actually have to skip ahead in memory 15/16th's of a tile after every 16 pixels. (Conversely, if you did just write to RAM in a linear sequence, you would get a block on the screen rather than a line.)

This isn't an issue if you use the graphics object to draw a line, but it is important if you're trying to implement a "getpixelcolor" function. I know how to do it for CGA graphics; I haven't worked it out yet for the Propeller's graphics.

In summary (please let me know if I have this right):

I.  Graphics consists of:
   A. a palette table
   B. a tile table
   C. a buffer that holds tile bitmaps

II. A palette table has:
   A. 1 to 64 palette entries
      1. Each palette entry has 4 "magic number" bytes 
          a. Each byte encodes Hue, Saturation, Luminosity 

III. Tile Table
   A. N times M 16 bit tile entries
      1. Each tile entry has a palette number packed in its upper 6 bits
      2. And the 10 most significant bits of a pointer into the tile bitmap buffer packed into its lower 10 bits

IV. Tile bitmap buffer
   A. Contains the actual pixels
   B. All the pixels of one tile are together, then the next tile, and so on
   B. All the tiles of a row are in order in the buffer, then the next row of tiles, and so on

Mike Green

Your summary looks correct.

Some little details:

As you might expect, the TV driver and the lowres VGA driver have different "magic number" formats and different screen dimensions, but are otherwise the same.

The text-only drivers treat each character cell as a tile and use a font table instead of a bitmap buffer, but are very similar in how they work.

The hires VGA text driver and the 512 x 384 VGA graphics/text drivers are different.