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

From: Greg King <>
Date: 2011-05-24 14:02:59
From: "Ullrich von Bassewitz"; on Mon, May 23, 2011; at 11:42 AM -0400
> What I currently fear is that we're changing the TGI API to be more
> logical and portable, but far harder to grasp. I easily can think of
> several people who will have problems if you tell them that they must
> allocate colors before being able to use them. And, that TGI_COLOR_RED
> is not meant to be passed to tgi_setcolor(); but, must be fed into
> tgi_alloccolor() first, which might generate an error. If not, the
> result then may be passed to tgi_setcolor().

A physical analogy might make it easier for people to understand what
they must do:

TGI_COLOR_RED and friends are like cans of paint.  tgi_alloccolor() dips
several (clean) brushes into those cans (and, gives those brushes those
colors).  tgi_setcolor() picks up _one_ of those brushes.  The other
functions paint the wall (the screen) with that brush.  When we want to
use another color, we pick up a different brush (which already has the
desired color on it).

Anybody who has painted things knows that it is a bad idea to dip a
brush into a can of one color; and then, dip that same brush into
another color's can.  Instead, we do either of two things:

1) We thoroughly clean the brush before we put it into the second can.
That is the same as freeing a color -- which TGI won't support.

2) We use more than one brush.  That is the same as calling
tgi_alloccolor() again and again, with each of the colors that the
program plans to use.

P.S. Hmm, I just had a thought.  Maybe, those two functions could be
renamed tgi_getbrush() and tgi_usebrush().  That might avoid confusion.

To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Tue May 24 15:48:50 2011

This archive was generated by hypermail 2.1.8 : 2011-05-24 15:48:52 CEST