Re: [AD] OSX IconTool

[Angelo Mottola <a.mottola@xxxxxxxxxx>]

I've just finished fixing my own version of the tool. Now it fully works;
check out the commandline options for info on how to use it; to fix the
Allegro demo program, try

tools/macosx/fixbundle demo/demo -d demo/demo.dat GAME_PAL SHIP3

The advantage of using my tool is the fact it is self-contained and does
everything in a single app (ideally to be put in the /usr/bin directory),
and that it is small (~20K compiled, ~5K gzipped source).
The disadvantage of course is it only supports Allegro supported image
formats for icons... But it can load bitmaps, rle sprites and palettes from
datafiles.
This however is in line with the other *fixicon tools, which are ideally to
be used inside multiplatform makefiles; for programs using them, it is
likely the icon image is already in bmp/pcx/tga format ready to be used by
wfixicon and bfixicon, so I don't think it's a problem.

> I used Tony's code because while Allegro does support a number of file
> formats, I've found that saving a PNG of the icon and using it to make
> icons under OSX tends to be the easiest way of doing things as well as
> the nicest-looking.  As well, using NSImage to do the loading gives a
> number of other advantages, such as easy blending and quality scaling.

About scaling, I'm using a compact bicubic resampler that gives pretty nice
results. Maybe not the best, but it does the job.

> (A side note -- Woudln't it be nice to extend Allegro's bitmap loading
> routine under OS X to support PNG images using NSImage?  We're already
> linking against the Cocoa library, so it'd be a "free" addition.)

Dunno about this. What about other platforms? If we do so under OSX, I think
it could be done also under Windows/BeOS at least. What do others think?

> I tried your tool, and it does seem to work aside from the empty icons.
> (I'd add change the -c feature to a -m (move) switch, and copy by
> default, however; but that's me.)  I'm thinking it could be one of two
> things: When you set the icon data of the family the data is just
> copying the pointer, and when you dispose of the handles you're
> disposing of the data.  The other thing it might be is that I noticed
> in Troy's code there's problems with creating an IconFamily as
> NewHandle(0).  (That's why his [IconFamily init ] doesn't work.)  You
> may want to try creating an empty icon suite and then converting it to
> a family.

After a bit of tests, it happens you *need* to always set the 1bit mask (if
not setting a 128x128 icon), 8bit mask and 32bit data for *each* icon size
you support; if you set just the icon data and one of the masks, it doesn't
produce a working icon. After discovering this, making it work was easy...

> Well, we now have two tools that do the same amount of work in
> different ways. ^_^;;  I can add the ability to pull icons from a
> datafile in mine, or we can scrap mine and just use yours.  Let me
> know, because if my two little programs aren't needed I won't continue
> working on them.

Humm, both versions have advantages and disadvantages, but I feel mine is a
little ahead of yours, due to compactness. Maybe someone else should judge
which one to use (anyone cares to comment?) :)

>> I didn't want to use Troy's code directly though as it adds a
>> LOT of unwanted overhead, and it uses Objective-C that I don't
>> think is necessary for the kind of application we're making.
>
> It's no different that the difference between C and C++
> performance-wise (as far as my tests have shown), and troy's code made
> it *extremely* easy for me to make the icon file.

I've not made performance tests on Objective-C, but its own way of working
makes me think it's a *little* slower than C or C++... I think so because
ObjC links messages to objects only at runtime. I may be wrong though as I
haven't read the docs on the runtime core yet.

About Troy's code, I think he made a great work, but it is not necessary to
us; if you look at my tool sources, you'll see that to actually set the
icons, only a few calls to Icon Service routines are needed. So in this case
using Troy's code adds bloat to me.

-- 
Angelo Mottola
a.mottola@xxxxxxxxxx

Attachment: fixbundle.c.gz
Description: Binary data