Path: chuka.playstation.co.uk!news
From: loonybit <ba124908@augsburg.baynet.de>
Newsgroups: scee.yaroze.programming.2d_graphics
Subject: Re: TIM
Date: Wed, 16 Sep 1998 18:11:44 +0200
Organization: PlayStation Net Yaroze (SCEE)
Lines: 70
Message-ID: <35FFE340.7B58F3E1@augsburg.baynet.de>
References: <35FE90A1.C741958C@augsburg.baynet.de> <35FED354.368F7092@shell.jps.net>
NNTP-Posting-Host: dial037.augsburg.baynet.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.05 [de] (WinNT; I)

I'll thank you all; you were a great help for me.

Thanks

Andy

Elliott Lee schrieb:

> Somewhat echoing James R., the way things are set up is:
>
>         # of bits per TIM       uses CLUT? table size
>         ----------------------- ---------- ----------
>         4                       yup        16 entr: 32 bytes
>         8                       yup        256 entr: 512 bytes
>         16                      nope       ---
>         24                      nope       ---
>
> For CLUT-based TIMs, you can think of them like GIFs.  Your
> image will have 4 or 8-bit integers, and each of those numbers
> maps to a color index, or the Color Look-Up Table.  For 4 bits,
> there's 16 entries, for 8-bits 256 entries.  Each of the entries
> is 2 bytes wide and is structured something like:
>
>          15   14-10    9-5     4-0
>         +---------------------------+
>         | t |   b   |   g   |   r   |
>         +---------------------------+
>
> One of the bits it a transparency flag.  The other 3 parts are
> the RGB values, 5 bits each.  So that gives you 32 levels of
> R, G, and B for a total of 32K colors.  When you take an
> image (e.g. BMP) and convert it to 4 or 8 bit format (with the
> TimUtil or through another program), the RGB colors are
> adjusted to fit for the 5-bits-per-color-channel scheme.
>
> So when a sprite is rendered to the frame buffer, each pixel
> undergoes a CLUT lookup and the final color is written to
> memory.  Of course, you're only limited to 16 or 256 colors.
>
> As for 16-bit images, they don't have CLUTs.  Each pixel is
> its own 16-bit value following the CLUT entry scheme above.
> This let's you get the full 32K possible colors on screen at
> once.
>
> And, if you want REALLY high color, then try the 24-bit images.
> 8-bits per color channel.
>
> loonybit wrote:
> >
> > Hi everyone,
> >
> > maybe a simple question, but can someone tell me:
> > How is an 8 bit CLUT constructed or represented in memory?
> > Are there three 8bit values (RGB) per color in the table (so 768 bytes
> > for the complete table)? Are the values in the TIM file indexes for the
> > table (0 is first entry)?
> >
> > Thanks,
> >
> > Andy
>
> --
> Mata ne,           ...                                          ...
> - e!             ::'              tenchi@shell.jps.net            '::
>   (Protocol)    ::  ACiD -/- ACS -/- pHluid -/- Yaroze -/- Nemesis  ::
>   (Tenchikun)    ::.           http://www.jps.net/tenchi          .::
>                    '''                                          '''