Re: [cc65] Re: TGI colors revisited

Hi Karri,

>> So the result is: If you don't want to redesign the roles of the TGI
>> kernel and driver on tgi_init() then tgi_getdefpalette() comes for
>> free.

> I like the possibility to call tgi_getdefpalette. It allows me to code like:
>
> tgi_getdefpalette
> copy the RGB values indexed by TGI_COLOR_BLUE to my own palette
> tgi_setpalette
>
> After this TGI_COLOR_BLUE works as before even if the rest of the colors in
> my own palette may be different.

I see. This is btw. exactly style of programming which depends on the
"rules" I described in my original posting.

>>> In order to allow the palette manipulation that you have described
>>> earlier, we must use the brush table as the TGI palette. [...]

>> If I understand you right than this approach wouldn't fit the
>> semantics of a palette. A palette means - at least from my perspective
>> - that setting a (different) palette immediately causes re-coloring of
>> all already displayed pixels.

> All indexed palettes work this way. This effect is frequently used for
> "animation" in games. A good example i Boing in Amiga where the sphere
> "rotates" due to manipulating the indexed palette.

I'm pretty lost now: Is the brush table an indexed palette? I've been
researching for more Lynx info but didn't come up with something
explaining how the 'brush table' and the '12-bit hardware palette'
work...

>> The usual approach would rather be to translate the values in the TGI
>> palette into values for the 12-bit palette on calls to
>> tgi_setpalette(). [...]

> This is a low-level driver. The tgi_getpalette returns a pointer to the
> hardware palette in the graphics chip. There is no stored "palette" in the
> driver.
>
> The only stored palette in the tgi driver is the default palette.
>
> Also the tgi_setpalette will just write to the chips registers directly. It
> will not store a copy of the palette anywhere.
>
> Some programmers even change the palette at start of each scanline to get
> more colors than 16 on screen at once.
>
> I like the current TGI-driver.

Again, I might be missing the point but... The whole story about TGI
is target-independence. Otherwise it wouldn't be explainable that it
i.e. doesn't have any sprite support.

Today any TGI program that works with palettes in any way is more or
less automatically target-dependent :-( The whole story about my
original posting is to extend the TGI idea of target-independence
toward palette manipulation.

It is obvious that TGI means for almost all targets that it doesn't
fully leverage the hardware capabilities. And that therefore TGI
(without proprietary extensions) is almost always not usefull for
getting the best out of the hardware.

If you say that you like the current TGI driver than I understand that
you can use it well for your Lynx-specific development. However that's
not the design goal of TGI.

If a TGI driver reports 16 colors than the palette used for
tgi_getdefpalette/tgi_getpalette/tgi_setpalette _HAS_ to consist of 16
'unsigned char's. If the Lynx TGI driver doesn't use such palettes
then it just doesn't comply to the TGI driver specification and could
therefore even considered not being a TGI driver at all.

Still it might be a very useful tool to write great Lynx applications
- but that's a totally different story...

> What we could do is to choose the best 16
> colors and give consistent names to them.

For the sake for target-independence I'd suggest - as discussed - to
use the C64 names.

> The indexes could also be in some
> kind of order of importance. Then every driver can pick as many colors of
> the palette as it can.

No, every target has - as discussed - it's own color macros. So
there's no need nor use in sharing color indexes between targets.

As the Lynx has "only" one driver there's nothing to share/pick from
for you. Just choose the indexes 0-15 as you like / as you see fit.

> I don't believe in the machine generated palette idea. It would not produce
> nice colors for such a limited palette. You would need at least 64 colors
> for making it work.

Once again I'm not sure if I'm understanding you correctly...

- The "fixed" colors 0-15 are supposed to be mapped to the 12-bit RGB
values using a manually finetuned table.

- The 6-bit color values and the TGI_COLOR_RGB(r,g,b) thingy was
really just an idea. However 6 bit yield 64 colors.

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.