Re: Questions on GS/OS Icon ($CA) files

Oliver Schmidt <ol.sc@xxxxxx> wrote:

Hi,

1. [...]

2. [...]

Thanks in advance, Oliver

Given the very lively discussion on my other question I'd really
appreciate if anyone could jump on this one as well - please!

I can probably find the details given time (don't remember enough about
this area of IIgs programming) but my functioning IIgs is at work (where
I can't read news) and all my manuals are in the process of being packed
away as I'm moving into a new flat. They might not get unpacked again in
the near future.

I'm working from rather rusty memory, so don't take this as gospel. Can
anyone else can chime in to fill in the blanks?

Most IIgs icon files are created with an icon editor application running
on the IIgs. I think I had a shareware one. There might have also been
tools supplied with some development environments.

When resources were introduced in System 6, I think they added support
for resource-based icons, which started to phase out the use of the
older icon files. I seem to recall that the whole system got easier at
some point - perhaps Finder was automatically keeping track of the path
to the application and storing it in a seperate database, no longer
relying on the fixed pathname in the icon file?

In earlier systems, the pathname field generally had to be patched if
you were going to install the application in an unusual location. Most
of them were set up on the assumption the application was in a fixed
path on the startup volume, which is referenced with '*' as a prefix,
e.g. "*:Applications:MyApp" (I forget the typical path).

If the application came with an installer, the installer might go to the
trouble of updating the icon file for you, otherwise you needed a
third-party icon editor (same as above) to patch the pathname field.

Few people (other than authors of icon editors) would have the technical
details of the actual image format committed to memory. The two icons
are probably 8x8 and 16x16 pixels but I don't recall how the individual
pixels are encoded. They are likely to be indexes into the standard
palette rather than RGB values.

The IIgs SHR mode is capable of displaying 12-bit RGB colours, but in
320x200 mode only has four bits per pixel, allowing you to choose from a
palette of 16 colours. Each row has its own palette, but most programs
set the entire screen to use the same palette.

The desktop GUI normally operates in 640x200 mode, which only has two
bits per pixel, allowing you to choose from a palette of four colours.
Since there are 16 entries in the row palette, Apple arranged the
palette so that each pixel in a group of four gets a different set of
four colours from the row palette.

In 640x200 mode, the palettes are usually set up with every pixel able
to be black, white or two other colours, and dithering is used to get
more colours by interleaving two different individual colours (or one
colour with either white or black), using an alternating pattern with
two colours available in the odd columns and two in the even columns,
thus only four distinct real colours are used on each line, plus black
and white. The effect is that you can choose from a limited palette of
16 colours but only pairs of pixels will actually produce the correct
colours (except for black and white).

For example, if your four colours were fully saturated red, green,
yellow and blue, with odd pixels able to be red or green and even pixels
able to be yellow or blue, you would have the following colours
available with dithering:

black (black, black)
dark yellow (yellow, black)
dark blue (blue, black)
grey (white, black)
dark red (black, red)
orange (yellow, red)
purple (blue, red)
pink (white, red)
dark green (black, green)
yellow-green (yellow, green)
blue-green (blue, green)
light green (white, green)
grey (black, white)
light yellow (yellow, white)
light blue (blue, white)
white (white, white)

Apart from the details of the order, this is the standard set of colours
in 640x200 mode.

Very occasionally a desktop program would run in 320x200 mode, which has
16 colours available for each pixel. Typically the colours of an icon or
other image would be completely different if the same icon or image was
displayed in 640x200 mode.

The dithering technique relies to some extend on the limited bandwidth
of the IIgs RGB monitor, which blurs adjacent pixels in 640x200 mode. It
is good enough for black and white (e.g. text) at close to full
resolution, but a group of alternating black and white pixels look more
like a grey block than vertical stripes.

--
David Empson
dempson@xxxxxxxxxxxxx
.

Relevant Pages

  • Re: What am I doing wrong here? Trying to draw 10 lines, multiple colors
    ... Therefore you change the color of the palette entry 1 and then plot ... the new pixels with color 1. ... Saves the current video mode, ... the video mode to its original value. ...
    (alt.lang.asm)
  • Re: resource editor
    ... icon toward the top left of the palette. ... Tim Wilson ... When I edit a 16 color icon in the editor, ... Select a color, or the transparent color, and paint on the ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Icons in VS .net 2002
    ... These may be the colors shown for transparent areas (which, ... I could look at an icon if you wanted to provide one ... transparent pixels to be. ... on the screen in the Visual Studio icon resource editor. ...
    (microsoft.public.vc.mfc)
  • Re: can anyone tell me why I get an error at line 19 with NASM?
    ... could be 'inc di' followed by 'inc cx' causing this ... I usually find that when the sun rises and the glare makes the monitor ... Maybe we can alter the palette to something prettier, ... Anyway, dream of pretty pixels! ...
    (alt.lang.asm)
  • Re: Problem with ATLs CImage and SetPixelIndexed
    ... OK, thanks Scot. ... experimenting to properly understand. ... a palette entry, which is not the same as an index into the color table. ... pixel bitamp which is 2 pixels by 2 pixels Set a color table ...
    (microsoft.public.vc.atl)