Icon Mania!

Posted by Alex Lee on 11 September 2012 | 3 Comments

Tags: Icon, IIGS, Finder, File Types, Resource Fork, IconEd, DiCED, GUI, Apple

My name's Alex...and I'm an icon-holic.

 

 

I never used to care about them much. In my futile quest to speed-up my original IIGS with 40 meg Vulcan hard drive, 2.25meg of RAM and ZipGS at 8Mhz, I actively deleted unattractive icons so the Finder would be that much zippier...if I even used the Finder at all, that is.

I'm a big fan of Ian Brumby's Instant Access v3, which I find is a faster launcher as well as requiring less memory after all the system add-ons you'd need to enable you to view pictures, read text and play sound and music from the Finder. Instant Access has always been tucked away in the system folder of the System 6.0.1 hard drive image with Shareware and Freeware games. You can run IA from the Finder or use the ‘Set Start' GUI based control panel to run Instant Access over the Finder when your IIGS boots. Another reason I'm biased towards IA3 is that I suggested it as an alternative program launcher to Ian after seeing Directory Opus on the Amiga way back around 1993. Ian had already thought about the idea himself and with two people coming to same conclusion independently, he decided to pursue it. If you go to the ‘About' menu and hold down some modifier keys, you might find a title screen easter egg I created way back when...

 

Instant Access

 

But let's get back to the point: In these days of blazingly fast emulators and solid state storage on the Apple II, there's little sacrifice to speed and ways to minimise memory usage (more on that later) to make the IIGS desktop experience all the more vivid through the use of icons.

So how do icons work on the IIGS?

When the first native IIGS Finder surfaced in 1987 a folder could be seen on the root directory of the 3.5" disk it came on called ‘Icons'. Around the same time, Apple released the Apple IIGS Icon Editor by Dan Olivier. It allowed users to edit or create their own icons right from the word go, although some aspects of the process could have been improved upon (and ultimately were with the shareware editors that superseded it).

Icons would be saved with a specific filetype ‘ICN' and each icon file could hold more than one icon. For each icon within the ‘ICN' file, you need to specify how the icon would be applied to executables, files, folders, etc. This could be done simply by specifying a filename. You could restrict the icon appearing for one type of file or executable by specifying the filetype for which it is intended. So if it's a GS/OS application you're wanting to ‘skin' with an icon, you'd specify its filename and ‘S16' as its filetype. This would ensure, for example, that if your intended executable filename is called ‘Rastan' that any document files that might also be called ‘Rastan' would not have the same icon applied to them. You could also ensure that any document with a specified filetype would always be applied with a specific icon simply by entering ‘*' as a wildcard for its filename. As an extension of the wildcard, you can also apply icons only to names with similar file naming conventions e.g. ‘Crystal*' would apply an icon to any files with the prefix ‘Crystal'.

You would also need to specify the path of the application that would open when the file is double clicked from the Finder. Using the ‘*' wildcard again, so a volume name of where the applications resides becomes irrelevant, you can then specify the application that will open files of specific filetypes, in this example, how it's specified that the ‘BASIC.LAUNCHER' executable will always open any BASIC files. But this is an easy example, as ‘BASIC.LAUNCHER' should always be on the root directory of a startup volume if it's included at all. You may need to specify the exact paths for applications to load from a double click on a specific type of icon which is a bit of a pain. However, there are utilities that can make this easier, such as Finder Binder FExt by Joe Wankerl which was made available only through GS+, by letting you choose how an ‘unbound' icon can call the most appropriate application when that icon is double clicked and remember that choice.

 

Apple Icon Editor

 

Off the top of my head, I don't know how the Finder resolves conflicts between icon allocation and which applications are assigned to open them. For example, you may insert a 3.5" disk which has its own icon files and while the current icons will automatically change the next time to open an application and quit back to the Finder, the icons MAY change to the icons found on the 3.5" you inserted. Anyone know how the Finder chooses which icons are displayed over another?

As another side-note, you can apply secondary or ‘auxiliary' filetypes to executables and files, which can help distinguish which applications ‘own' the same filetypes. This is only as good as the apps that support saving the auxiliary filetypes when any files are saved (for example, Apple preferred graphics format ($00C0) but using an auxillary filetype stamped to the file to differentiate between Platinum Paint and Dream Grafix, which both apps use the same format for). But I still don't know how the Finder prioritises between which applications have ownership over a certain filetype with the same primary and secondary filetype information.

Anyway, remember that folder on the root directory called ‘Icons'? All icons need to reside there for the IIGS Finder to know where to find them and then apply them as per the specifications given to each and every icon.

Things got a little more complicated after the release of System 5 in regards to icon creation, but this made it easier for the average user, as icon handling could now be done entirely behind the scenes and without specific paths to applications (which is a major pain if you move apps into other folders or change their filenames) or even fighting over which app got to load when the icon is double clicked within the Finder.

With the inclusion of forked files, icons could be placed within the resource fork of a file or GS/OS executable, which would then be contained in a ‘Desktop' file, sitting in the ‘Icons' folder, which collects all such icons automatically after opening these applications for the first time. But, for the sake of backwards compatibility, even System 6.0.1 supports the older style method of applying icons, which is a good thing given that the majority of commercial software was released in the early days of the IIGS and that their icons could keep working as GS/OS progressed.

Pretty as a Picture

So far I've only discussed the deployment of icons - not the creation of their artwork.

Firstly, there are two icon sizes - large and small. Large icons are seen in the default window view within the Finder. Small icons are used in list views. I'll only be talking about the large view from here on out, as creating small icons for all these apps would double the workload required for what I'd like to do with IIGS icons...too much work!

 

Small and Large Icons

 

Although icons are intended for the IIGS Finder, which uses the super hi-res 640 x 200 video mode, all the icon editors I've played with including Dave Lyons' DIced, Steve Disbrow's ICE (only available through GS+) and Paul Elseth's IconEd v2b3 (does anyone have a newer beta version of this, or even a final v2?), treat the creation of icon artwork as if they were 320 x 200 resolution graphics. You can use tricks like using the two ‘grey' colours (which in fact are narrow strips of black and white in 640 mode) to get sharper edges where black and white meet and contrast. This limitation of treating them like 320x200 mode graphics could be related to how icon masks are used; there may be other limitations I'm not aware of as well.

 

Example Icon Editing

 

However, you can still use paint programs that make better use of 640 x 200 mode graphics and its particular quirks and import them into icon editors. But more on that later.

One last important note to do with ‘large' icons' artwork is their size. Unlike the classic Mac OS, for which its large icon size has always been locked to 32x32 pixels, IIGS icons can be as large as ‘160 x 50' pixels. However, just because you CAN make icons that large, doesn't mean you should. An issue you'll quickly run into with really large icons is that they will begin to overlap onto other nearby icons on their grid. It's best to stick to the 16x16 default for IIGS icons and only use larger icons for executables, where you can layout the icon within its windowed folder (which is remembered in the invisible ‘finder.data' files in each directory) so that it becomes obvious which icon to double click to start a program.

The Heart of the Mania

Without banging on any more as to the intricacies of how icons work on the IIGS, let's get to the core of my icon infatuation: creating icons for as many programs (mostly games) that never came with an icon.

Why did so many IIGS programs never come with an icon? For many, it made perfect sense not to as they weren't functional from the IIGS Finder in the first place. Most IIGS games booted directly into the game from disk, completely skipping the Finder and the need to double click an icon. Furthermore, most of these games wouldn't run properly when attempted to be launched from the Finder even if you tried... at least until some smart individuals created patches so they would work. Since those patched versions, it is now possible to run them from the Finder, with or without an icon. But not only does it look more aesthetically pleasing to include an icon, it will also help identify which is the correct executable to double click (older games may have had multiple executable files that the program would refer to, but only one would launch properly).

Given I've spent a long time (and the search is not yet over) trying to find as many GS/OS compatible and hard drive installable patches for IIGS games and apps, I finally decided they may as well look good at the same time.

In my quest to better skin all these games, I turned to all the icons I've assembled for the System Add-ons volume to poach whatever icons have already been made by others for programs that never had an icon. And that yielded some good results - a nice helicopter icon for Cavern Cobra...a great periscope view for Sub Battle Simulator...a palm tree for California Games...a nice, but overly large grab of gameplay from Warlock, which I then cropped and resulted in a more succinct visual representation of the game.

That's the trick with icons. They're ICONS. Not illustrations. Less is more! Many icons from the System-Add-ons collection are too large, detailed and unfortunately downright ugly in a lot of instances and I would never use out of desperation for a complete icon set. So I then started to strip down some of these illustrated icons, which bore more fruit - the silhouette of the Hover Blade craft proved a good icon when removed from its planetary background, for example.

Another Source for Good Icons

This then lead to me using in game screen shots for sources of icons - finding something the right size from the action that hopefully sums up the game nicely in a single, simple logo style image: a tank from Firepower; the darting crystal bonus from Crystal Quest; the magic fruit that would revive your father in King's Quest IV or the giant holographic alien head from Space Quest I. Effective icons if I do say so myself.

 

From a DOS screenshot

 

For some of these icons, I didn't even refer to the IIGS screen grabs I've been exhaustively collecting for the coffee table book. Knowing full well that the EGA colour palette bares more resemblance to the 640 x 200 mode default colour palette, I took DOS screen grabs of Fire Power and Neuromancer from mobygames.com, removed all the elements I didn't want to include in the icon in Photoshop before importing into the IIGS and converted those to 640 x 200 mode graphics using Super Convert 4. Once converted, you can then crop images to be as small as possible and then save as an ‘ICN' file directly out of Super Convert 4. From there, I load the ICN into IconEd v2b3 (my preferred icon editor), create masks for the icons and properly allocate the filename and filetype for the icon. Dropping the resulting ICN file into the ‘Icons' folder of the root directory of the volume in which the game sits, the icon then magically appears the next time the Finder is restarted.

IDIY (Icon Do It Yourself)

But then I had to go one step further. Creating icons from scratch. Using Platinum Paint (which I'd already used for editing of existing icons) I used its broad toolset to create the marble from Marble Madness and adding a similar motion effect as seen on the game's box. But my favourite is the icon I made for Gauntlet. Using the gargoyle head found on the character selection screen and arcade cabinet art, I was able to recreate it as faithfully and as small as possible. This is the result:

 

Gauntlet Icon from scratch

 

Who'd have thought the icon could look better than the in-game graphics? :-)

Last, but certainly not least, is combining all icon files (that I used to keep separately) into one file using copy and paste or drag and drop within IconEd. Why? Chiefly, because it saves disk space. A single icon file might be 1k big, but the actual data isn't that much. If you can squeeze all icons into a single file, the sum total of the actual data is saved to a single file and not the minimum file-size of all the separate icon files. I conserved 60k from the System 6.0.1 with Shareware and Freeware games image and while that doesn't sound like a lot, I could then fit another 2 to 3 simple games on it. Getting the most out of that 32 meg ProDOS volume limit is something I'm always keen to maintain.

 

All Adventure Game Icons in one file

 

Comparing the memory usage by going to 'About the Apple IIGS' from the Finder between the older System 6.0.1 image with the newer one with combined icons, it saves on memory too - looks like I saved 100k to be precise! And hopefully, it should also make the pauses when volumes mount on the desktop shorter as well, an issue I first mentioned in my review of the CFFA 2 card.

One last final note:

I still haven't managed to create icons for EVERY game. It's proving a mammoth task, and rather than not release anything until every game is accounted for with an icon (which might never happen), I've decided to release what I have so far. Currently that means we've got icons for EVERY action game (that needs one anyway, as Alien Mind and GATE will NEVER run from the Finder). We also now have icons for NEARLY every Adventure game, most icons for RPGs, quite a few for Simulations and Board Games, but really short on Sports and Unreleased games.

So if you've held onto an amazing icon since the IIGS' halcyon days for that favourite game, please pass it on. Or maybe I've inspired you to create one from scratch? Check over all my updated 32 meg volumes for missing icons and I'd love to hear from you if you can fill in the gaps. While you're checking for missing icons, check for any missing hard drive installable games as well - we're still in need of a few... however, I've also got a trick up my sleeve for more hard drive installable versions, thanks to some text files that are on the recently reclassified TABBS CD-ROM (thanks Ewen!). Stay tuned for more.

In the meantime, be sure to grab my updated 32 meg volumes:

 System 6.0.1 Hard Drive Image (now with many more icons for its shareware and freeware games included)

 Action Games

 Adventure and Simulation Games

 Board Games and RPGs

 Sports & Unreleased Games

 Utilities & Aural Creative (Where you can find icon editors under 'SW.Utilities/Icon.Editors')

 Productivity & Visual Creative 

 System Add-ons (the source of many icons – check out 'Icon.Library')

UPDATE! I've added a lot of new icons. While it's still not a complete collection, we've mostly got Sports covered now, most Unreleased Games covered and a couple more Sim games. As always, if you can contribute with some icons of your own, it would be much appreciated.


Post your comment

Comments

  • Thanks for the heads-up Kelvin! Too slow this time Antoine ;-)

    Posted by Alex Lee, 12/09/2012 12:54pm (2 years ago)

  • Programmer's Reference for System 6 says:

    When starting up, the Finder loads icons from each device from lowest numbered on-line device (#1) through the highest numbered on-line device. On each device, the Finder first loads any Desktop file from the icons folder, then loads all non-inactive old-style (Pre-Finder 6.0) icon files in the Icons folder. When the user inserts a disk, the Finder first loads the Desktop file from the inserted disk, then converts all the old-style icon files.

    The Finder searches for icons based on the order they were loaded. This means that the Finder will look through the icon from device #1 first before looking through all the icons from device #2, and so on.

    Because of the order that icons are loaded, icons attached to rBundle resources in Desktop files will be matched first before an icon which is set to match the same criteria in an old-style icon file.

    Within Desktop files, the Finder loads rBundle resources sequentially, from lowest ID through highestID.

    Finder searches through the OneDoc structures from the first loaded rBundle to the last loaded rBundle.
    The Finder always searches its built-in icons last.

    --

    Also worth noting: rBundle type icons could match based on name, file type, aux type, creation date, modification date, file access, resource fork, HFS file type, HFS creator type, and file size.

    Posted by Kelvin Sherlock, 12/09/2012 3:59am (2 years ago)

  • I will answer to your questions. I have the answers somewhere on my hard disk drive.

    For clarification about the $C0 filetype, both apps share the same filetype but the format (to me, the compression method used) is different.

    Antoine

    Posted by Antoine Vignau, 11/09/2012 8:08pm (2 years ago)

RSS feed for comments on this page | RSS feed for all comments