I thnk I finally understand (most of) the tile colour map examples
PatM
Posts: 72
From the Hydra examples:
· 'init colors
· repeat i from 0 to 64
··· colors[noparse][[/noparse]i] := $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)
"screen" is not the bitmap to be displayed,·it is·the colour matrix to apply to the·bitmap (the naming threw me off for quite a while). Part of the confusion was the declaration of "word screen[noparse][[/noparse]X-TILES * Y_TILES]".
Each tile requires 32 bits of colour information and this only reserves 16 bits for each tile. It took me a while to figure out that screen doesn't hold the colors, it holds the pointer to the 32 bit color table entry that has·four colours defined (the long colors[noparse]/noparse array).
Where I completely lose it is the dx & dy loops. the start of the bitmap memory is incorporated into whatever is happening there, as if the colourmap is being applied to the pixel pattern for the display. I know you can't do that as it'd just trash whatever image you were trying to build. I would have thought you could just iterate through the screen array and copy in the pointer to the appropriate colours[noparse]/noparse entry.
Anyone up to explaining what happens in those loops (obviously it works, so its not wrong).
·
· 'init colors
· repeat i from 0 to 64
··· colors[noparse][[/noparse]i] := $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)
"screen" is not the bitmap to be displayed,·it is·the colour matrix to apply to the·bitmap (the naming threw me off for quite a while). Part of the confusion was the declaration of "word screen[noparse][[/noparse]X-TILES * Y_TILES]".
Each tile requires 32 bits of colour information and this only reserves 16 bits for each tile. It took me a while to figure out that screen doesn't hold the colors, it holds the pointer to the 32 bit color table entry that has·four colours defined (the long colors[noparse]/noparse array).
Where I completely lose it is the dx & dy loops. the start of the bitmap memory is incorporated into whatever is happening there, as if the colourmap is being applied to the pixel pattern for the display. I know you can't do that as it'd just trash whatever image you were trying to build. I would have thought you could just iterate through the screen array and copy in the pointer to the appropriate colours[noparse]/noparse entry.
Anyone up to explaining what happens in those loops (obviously it works, so its not wrong).
·
Comments
The words of SCREEN contain the index to the 64-element COLORS vector in their highest 6 bits only.
The lower 10 bits contain an index to the tile where this color scheme - as described in the "color-element"- shall be applied to. 10 bits suffice, as each tile is 64 bytes long.
Thus a tile (and the bitmap ONSCREEN-BUFFER as well) must always start at an address which is a multiple of 64.
Post Edited (deSilva) : 7/8/2007 2:58:03 AM GMT
The info you want is near page 14 of this PDF. There is one error in the text, and that is the tile addresses fill horizontally and down, starting from upper left, ending at lower right. Otherwise it contains all you need to know on this topic.
My manual is kind of hard to read as its now about 200 pages shy. Every time I try to read something, a pile more pages come loose.
I gotta get off my butt and warm up the hole puncher.
·
When I get stuck (and that's fairly often!), re-reading that stuff always helps. Some aspects of the prop are just really different. Makes it tough to grok the first time through, but is way cool once the light goes on!