Speechless, that is a lot of great artwork here.
And yes the grey has some appeal, it's just isn't that a bit to easy?
I mean you need a lot more creativity when you limit yourself to the WB1.3 4 colors as if youn can make a "full colored" icon.
The effect of the blending on a crt is unique i remeber well (means i haven't one now, wrong i would but i didn't used it yet, my amigas still hybernate).
gybrish, i wouldn't say totally different but straightforward, it's the proper idea to keep them small (even if mine are oversized often), the are clear and easy to recognize and that is an art of its own. Further i like that you kept a consistent size for most or as i see for all what is WB related, games can differ since they stand in specific directories.
No you don't have to feel sorry intri8 yours are brilliant to.
To the smallness, it sure helps on a floppy driven system but it seems to me you don't gain much with the size (at least that is what i experience emulated, i need to fix my A500) the amount is what eats up most, no matter 128x64 if them are only four the are splattered in "no time" on the screen, but 20 small ones take a long time to be loaded.
Erm yes, i used for a while a PD LoadWB and icon.library, the (superficial) slight difference is that the icon.library uses fast ram if affordable, it draws the icons a litle bit faster especially if they are many.
But avoid it, it can make sense to use it for a redistributable floppy because this is free of licensing.
It took me some time to find the leaks within and i almost forgot them, however it can be a troublemaker under certain conditions. For a common use like to start a program from the WB it will be fine but not for your OS you daily run.
That is
a) (PD) LoadWB leaks of the debug switch
b) certain times the info.library (which is called if you like to edit the tooltypes and such) get's confused and freezes the machine. This happens not often but even sparse this isn't to accept for a daily use, like i said fine if it's a redistributable but not on your system you use.
There is another issue which i recently don't remember, i tossed it and due to that i lost interest in it - or vice versa.
Because i would have a ton of icons - i won't show them off here
Or maybe one or so...
Many of my icons aren't truely animated, that is because sometimes i just don't have the right idea and sometimes it's just not needed or as good as if you don't, the use of inverting colors can be a challange of its own.
Following is a "not but"
means it isn't really animated except that i invert blue and orange i did this for a lot of icons since i feel that is enough and the orange color is good indicator that something is running, respectively that you clicked on this icon.
Besides the purpose of "flush" is either to flush T: (erase all) or to flush ENV: (rebuild)
Both makes sense if you script a lot since this will fill T: very soon under circumstances, same for ENV: it can be full of garbage, flush it! (respectively rebuild it, since i use an ENVARC: similar as for later releases)
The absolute opposite to my large icons are the tiny ones i have stored - guess where...
in ENVARC:SYS which i use as default icons if i create a new file or directory (some 2.x magic for 1.3).
They are for reasons of smallness not animated an make simply use of the inverted state.
Which makes them to a sort of radio buttons.
In principles this would be enough as an icon.
Erm smallnes, you like to keep the icons small in byte count?
Let have Doctor Icon put his knife on it, i see the program you use is nice but let me have a look at the byte count.
Since most (but not all) store the canvas double (just like the use of iconmerge) for an animated icon, that isn't needed the canvas only has to be stored once in the icon, further the canvas doesn't needs to be a true bitmap but that is usually the case, let's assume your icon is 40x20 these are 800bytes of zeros, ZEROS! Doctor writes this as an instruction and not as a bitmap which shortens size and loading time again.
As result an icon created with Doctor can have almost half of the size of an icon created with any else tool.
Nope, Doctor icon icons are 100% compliant, he just made use of his head.
Yes there is a drawback, programs which will convert an icon to C or similar usually expect a canvas as a bitmap and not as instruction and won't understand this, but well Doctor helps even here.
Why does it store the canvas at all if the canvas size is defined at beginning and what is the difference?
As far as i know the stored canvas allows that you can see the icon image if the icon is dragged around on the Workbench, without it it would display the background as soon as moved out of position, at least that's what i learned from the documentation to wIconify.
Further you can abuse (yes it's an abuse) the definition for the canvas size to move the text under or in the icon, just add or subtract the amount of pixels, the "proper" way would be if you like to have a spacing of two pixels for the text to leave two pixels blank, e.g. just like 1.3 IconEd the maximum size would be 80x40 but you have space for 80x42 to reach the two pixels of spacing. Theoretically you can even abuse it to remove the spacing between icons, if you subtract a single pixel from the canvas width the spacing is gone and one icon will be positioned at the other with zero space between, not very useful but possible. On the other hand very large icons like i.e. 128x64 will by default leap one in the other (the spacing for the icons is fixed that is also why a 50 pixels wide icon has exactly the same spacing to the next icon as a 80 pixels wide, when floated, when you clean the directory up the spacing will be caculated new). If you would add width to the canvas size you could get rid of the overlap with the drawback that this moves the text out of the center. One can see the 80x40 maximum is a systemwide maximum larger is possible but isn't supported well.
But hell that is great stuff here!