Re: [cc65] TGI palettes (was: TGI colors revisited)

From: Oliver Schmidt <>
Date: 2011-05-15 18:54:35

>> Hmm, do we really want to go into color approximation? What is the
>> metric for similarity? I'd rather go for a simple "Either I have what
>> you ask for, or I don't". The additional function allocating colors
>> from RGB values (see above) maybe could allow for approximation.

> An obvious metric is "use the dark color when the light/bright version
> isn't available".

Hm, "obvious" might easily be sort of subjective... The Apple II
perspective: The hires mode allows beside black and white for orange,
blue, green and violet - no palette. You see - it's especially
annoying that red is missing. From that perspective a hue based
approximation would be most useful. It would return the orange color
handle when asking for red and thus allow to run programs asking for
red, green and blue...

>  But, a program might need to know when it must use
> some method, other than a bright color, to highlight a graphics figure.
> Therefore, _automatic_ approximation is a bad idea.

Full ACK.

>> However, I somehow feel that the background color is somewhat special.
>> What exactly is the description of tgi_clear()? Maybe, the color
>> allocator should return one color less than the driver can display, to
>> keep the background -- and thus, the behaviour of tgi_clear() --
>> consistent (and, to avoid the re-colorring of the background)?
>> But, that would allow for only one single color allocation
>> on monochrome drivers.

> And, we could not use the background color to erase pixels.

Okay, I'll give it a try:

From a technical perspective tgi_clear() sets the frame buffer to the
value zero. But the the collor allocation approach means that colors
are opaque handles - so zero has no special meaning. The app has no
way to handle interaction between color allocation on paletted drivers
and the result of tgi_clear(). The only outcome of this issue can be
that tgi_clear() has to go. It needs to be replaced by
tgi_fill(unsigend char color). With that change all (?) drawing TGI
primitives would work with some explicitly given color value.

Another somewhat related aspect is the semantics of tgi_init(). In the
current cc65 release it does an internal tgi_clear(). However after a
discussion I initiated we decided to drop that functionality from
tgi_init() - which is the case in the current snapshot. But what is
still left is that tgi_init() does an internal
tgi_setcolor(TGI_COLOR_WHITE). I see two options:

1. Remove that tgi_setcolor(TGI_COLOR_WHITE) from tgi_init(). That
means the app needs to take full control over allocating the color
handles it needs.

2. Have tgi_init() do an internal tgi_alloccolor(TGI_COLOR_WHITE) -
and for consistency probably tgi_alloccolor(TGI_COLOR_BLACK) too - and
then the tgi_setcolor(white). Most likely that would mean to introduce
something like two "standard color handles" sort of similiar to the
three standard file i/o handles. Apps interested in black&white only
could use those standard handles and get along without any explicit
color allocation calls.

Probably 2.) is preferable because b&w apps would look like today with
the one exception of tgi_clear() being replaced by
tgi_fill(TGI_STD_BLACK). I don't know if a wrapper to that call named
tgi_clear() would actually be beneficial or rather confusing...

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Sun, 15 May 2011 18:54:35 +0200

This archive was generated by hypermail 2.1.8 : 2011-05-15 18:55:15 CEST