Colors initialisation

Roi

Hi again

I understand from the Graphics_Palette.spin, that there are 64 possible colors, but·only 4 colors are allowed per square on the 16*12 squares on the screen.

Is it not possible to have, say, just 16 or 8 colors, but all of them accessible on every pixel?

Further, I just can't seem to understand this color & tile initialisation process. (I have many years programming experience, but not this lowlevel)

From Graphics_demo.spin:

'init colors 
repeat i from 0 to 64 
  colors[noparse][[/noparse]i] := $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)

Can someone please explain it to me, or point me·to some litterature explaining it, so that I can make my own custom colors?

Thanks

Paul Baker

It is not possible to use the Video Peripheral with more than 4 colors in each tile, if you look at the details of the VCFG and WAITVID you'll see there is only the option of 1 bit or 2 bits of information for each pixel is possible. I was trying to think if you could somehow trick more colors out by using the VGA mode, but Im pretty certain that's a dead end since the color in TV is generated by phase shifting the color carrier signal.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life is one giant teacup ride.

Kaos Kidd

I'v an idea Paul, that's along the same lines as your suggestion, but somewhat different.
Back in the Old C64 days, they (not me, thats the BFZ) used raster intrupts, and on the intrupt, we overlayed additional bits into the color registers.
I know timing is all in video, but the idea would be to have an exact sync for the color data, and when needed, overlay additional bits from a seperate small table.
Well, what do you think?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Roi

Ok, hmm. This means very careful planning, when designing layouts then.

I could have sworn though, in that promo video featuring the "Hydra" in action, by Andre Lamothe, that the colors in the last part of the demo were exceeding 4...

Thanks again Paul

Paul Baker

I dont think it possible to do that, since the Video Peripheral operates on a "grab and go" principle, once it's grabbed the color and pixel information, it does it's own thing out of reach of anyone until its ready for the new information. The idea did make me think of a potential alternative though, and thats using two seperate video cogs which are synchronized (I don't know if this is possible), each is outputing its own chroma signal and luminance, the two signals are averaged together with a bit of external circuitry to produce a 3rd chroma and luminance value. This in theory could produce 2 bits of color information for every cog video peripheral used for possibly 2¹⁶ colors.

Interesting point about the Hydra, I have a vague recollection of Andre talking about this in the demonstration in Rocklin I saw but I can't remember precisely what he said. He may be using color averaging by varying the colors in a stippled pattern since he uses two cogs to generate alternate raster lines.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life is one giant teacup ride.

Post Edited (Paul Baker) : 7/7/2006 7:59:39 PM GMT

rokicki

Well, the limit in WaitVid and VideoCfg only applies on a per-instruction basis. Therefore, this limit applies, but it is kind of
meaningless because potentially a tile only has to be one raster row high. Further, if you shift the pixels out very fast,
much faster than you can change them, you can have a lot of tiles horizontally as well, and therefore a lot of colors. The
real limit is how you put that information in only 32K hub memory and how you get it into the WaitVid instruction fast
enough. That is, it's a simple matter of programming.

That said, of course if you use the supplied graphics object with its video pipeline cog, you also get its limitations.

Phil Pilgrim (PhiPi)

Theoretically, you can assign any color to any pixel, on a per-pixel basis. The video generator doesn't necessarily have to shift 16 pixels in four-color mode for each waitvid. It can shift four, each pointing to a different color. But you have to work fast to get the color table and pixel map set up in time for each waitvid! Plus, there's all that RAM. But that may not be so bad. If you limit yourself to 16 colors, each pixel needs only half a byte. And you don't really need to take up the whole screen. 240 x 180 pixels would need 21.6K bytes, for example; 120 x 90: 5.4K. If you still want to fill the screen, you can use two lines for every pixel and make the pixels extra wide. The latter will help with the waitvid deadlines, too.

With the Propeller, there's more than one way to skin a cat!

-Phil