icon.library 46.4 test versions

[PeterK]

Icon.library 46.4.284 has been released on Aminet:

http://aminet.net/package/util/libs/IconLib_46.4

IconDemoADF.lha

To make it easier to use my icon.library under OS 3.0+, I've built a demo ADF that shows how to get things to work. Just copy this image file onto a disk and then boot from it. It displays all types of icons: old icons, MWB-icons, NewIcons, GlowIcons, OS4-icons and PNG-icons. And it does not even need SetPatch v44 or the workbench.library. It works with LoadResident instead, uses icon.library 46.4.271 and the new faster colormapping. FBlit needs no ChipMem for the icons and the NewIcons patch makes even transparent backgrounds possible. DefIcons and NiPrefs are included. AutoUpdateWB and SwazInfo are also installed. Works with Kick 3.0 already. Please read the NewIcons.guide from the original package. http://aminet.net/package/util/wb/NewIcons46

[Thorham]

Cool But how do I use this (3.0)?

[PeterK]

It works with ClassicWB (tested ADVSP), Scalos 1.2d and OS 3.0.
No need to get any OS 3.5+ files !

http://eab.abime.net/showthread.php?t=63342

http://eab.abime.net/showpost.php?p=810622&postcount=36

[mfilos]

Will report back from home Peter mate
Cheers once more for these updates \o/

[PeterK]

Some additional information concering the icon.library:

How to use LoadResident with icon.library and workbench.library and save 200 kB FastMem ?

There is a problem with SetPatch which does not realize that LoadResident has already loaded these libraries into memory, although the same procedure seems to work perfectly with LoadModule. But it does not !

SetPatch needs the option DISABLEROMMODULES ""
For example: SetPatch QUIET SKIPROMMODULES scsi.device DISABLEROMMODULES ""
Add the following lines or something similar to your startup-sequence:

 
C:Version >NIL: exec.library 45
If WARN
   C:LoadResident >NIL: LIBS:icon.library
   C:LoadResident >NIL: LIBS:workbench.library
EndIf

C:SetPatch QUIET DISABLEROMMODULES "" ; plus other options like SKIPROMMODULES ....

How to use LoadModule with icon.library and workbench.library ?

Although it seems to work for LoadModule without this trick, I've checked it out and ...
surprise, surprise, you can save about 180 kByte FastMem even with LoadModule, but LoadResident is even better in saving FastMem, it needs nearly no extra FastMem at all. Add something like this to your startup-sequence:

C:LoadModule >NIL: LIBS:icon.library LIBS:workbench.library NOREBOOT
C:SetPatch QUIET DISABLEROMMODULES "" ; plus other options like SKIPROMMODULES ....


Something else: Important for users of DOpus Magellan II:

Make sure that the newicon.library V44 is installed in your LIBS: drawer.
And activate "Smart Icon Copying" under the DOpus "Icon Settings".

[SpeedGeek]

I thought you could just copy the latest version of icon.library to libs: and it would automatically be used if it's newer than the ROM based version?

I think I have 40.4.209 in ROM and I really don't want to burn a new ROM for every update. I don't like LoadResident any more than I like OSRomUpdate!

[mfilos]

Tested it tonight and it works just fine (as the previous version did).
Haven't tested thoroughly all the new features but will report once I test them out

I agree SpeedGeek that is annoying burning new ROM for the new updates. I use ACATune's MapROM feature which rox, but it would be really awesome if we could make something like ROMflash at some point to get over with all this stuff

[PeterK]

I would agree to that it doesn't make much sense to put the icon.library into an eprom and burn a new one for every update. Maybe, if it were a flash rom. Nevertheless, it has a lot of advantages to use custom ROMs with WinUAE or BlizKick or other ROM emulaters. You have shorter boot times and building a new ROM image is quite easy with Remus.

But many people are using LoadResident or LoadModule to make these libraries reset proof. This needs an extra reset only for the cold start which is neccessary for SetPatch in any case, but it speeds up all further reboots later. And that's where they should take this SetPatch option into account.

If you don't use it then SetPatch will always try to replace the resident icon.library and workbench.library with those that can be found in the LIBS: drawer, exactly as you said (but maybe without checking the version). As a result, LoadResident calls will get useless and fail and for LoadModule calls SetPatch will just waste memory by loading these two libraries again.

To avoid this either use SetPatch DISABLEROMMODULES "" or alternatively you could rename these libraries to prevent SetPatch from finding them in LIBS:.

ok, mfilos was a little faster
Thanks for testing, mfilos !

[_mandark_]

icon.library 46.4.230 running fine so far on my system (A1200, ACA1230-56, OS 3.9 on 4 GB CF-card).

[clauddio]

Originally Posted by PeterK

Something else: Important for users of DOpus Magellan II:

Make sure that the newicon.library V44 is installed in your LIBS: drawer.
And activate "Alternative Icon Copying" in the DOpus settings.

I'm using dopus 5.82 ( last version)
where is the option "alternative icon copyng" ? I can't found it

[PeterK]

Sorry clauddio, I was using DOpus Magellan II with German localization and the options name was "Alternatives Piktogramm Kopieren", so I thought that the translation should be "Alternative Icon Copying". But now I've changed the localization to English and that shows me under "Icon Settings" that the option is called "Smart Icon Copying" instead.

@_mandark_
Thank you for your report

[PeterK]

Updated to icon.library 46.4.231

[NovaCoder]

Cool I will get around to installing this soon, thanks for your work

I'm running an AGA WB OS 3.9 BB2 and RemapApollo (works like BlizKick).

I assume I can just give this icon.library to RemapApollo and it will be all good?

This library will be faster/better than the BB2 version for an AGA user?

[PeterK]

As already mentioned above, when loading icon.library and workbench.library resident, like it is done by RemApollo or BlizKick too, then you can save about 200 kByte of memory by using SetPatch like this: (important is the empty string "" )

C:SetPatch QUIET DISABLEROMMODULES "" ; plus other options like SKIPROMMODULES ....

If you don't use this SetPatch option, then loading these libraries resident is absolutely pointless, because SetPatch would remove them from the resident list and will load them again. The empty list = "" means that it should not disable any ROM modules.

I'm always trying to improve the library with every new release. The next version will come out very soon here....

[daxb]

You can load the icon.library with RemApollo as a module. I tested that on a A1200 Apollo 1240 OS3.1 system. ...and additional what PeterK wrote. You can check with e.g. Scout if resident loading worked.

[NovaCoder]

I just use NOROMUPDATE for SetPatch and then pass in all the updated modules separately to RemapApollo

[PeterK]

Originally Posted by daxb

You can load the icon.library with RemApollo as a module. I tested that on a A1200 Apollo 1240 OS3.1 system. ...and additional what PeterK wrote. You can check with e.g. Scout if resident loading worked.

Better check with "Avail FLUSH" directly after booting has finished.
And compare it once with SetPatch DISABLEROMMODULES ""
and another time without this option.

I would predict and could bet that NOROMUPDATE will not prevent SetPatch from disabling these two resident libraries and loading them from LIBS: again. They may still appear in the resident list, but they are disabled there. Only Avail FLUSH can show the difference.

[_mandark_]

Was testing the new version on my A1200 and WinUAE (A1200-clone, Picasso96, uaegfx) yesterday. No big problems whatsoever, but I encountered a freeze on WinUAE when saving all drawer icons in a drawer (about 160 blue and green colored drawer icons). But I was not able to reproduce the crash...

[PeterK]

Hmm ? I never encountered such a problem yet.
Please, give me some more details in case it occurs again. (example drawer icons or the name of the icon collection they belong to)

Maybe this could also be an issue of the new dos.library ?
I guess, you are using it, but I didn't try it out yet.

[PeterK]

Updated to icon.library 46.4.235

[_mandark_]

Originally Posted by PeterK

Hmm ? I never encountered such a problem yet.
Please, give me some more details in case it occurs again. (example drawer icons or the name of the icon collection they belong to)

Maybe this could also be an issue of the new dos.library ?
I guess, you are using it, but I didn't try it out yet.

Your guess was right, I am using the new dos.library But I also have not encountered this problem again. Your latest icon.library is running fine on my systems.

[PeterK]

Updated to icon.library 46.4.237 (Be careful, this is just a snapshot, a nightly built from a drunken coder)

BTW, the icon.library is now completely based on my own source code. It is finally independent and free of the AmigaOS copyright restrictions.

[SpeedGeek]

@PeterK

If you can produce such excellent and awesome code when drunk imagine what you could do sober!

[matthey]

Originally Posted by SpeedGeek

@PeterK

If you can produce such excellent and awesome code when drunk imagine what you could do sober!

Maybe worse. Alcohol releases creativity in studies:

http://www.medicaldaily.com/news/201...vity-study.htm

Originally Posted by PeterK

BTW, the icon.library is now completely based on my own source code. It is finally independent and free of the AmigaOS copyright restrictions.

Congratulations. This is a great milestone achievement to be complete and free at last .

[gulliver]

Originally Posted by PeterK

Updated to icon.library 46.4.237 (Be careful, this is just a snapshot, a nightly built from a drunken coder)

BTW, the icon.library is now completely based on my own source code. It is finally independent and free of the AmigaOS copyright restrictions.

Congratulations!!!

Now perhaps, you can drink some more, and recreate and make free another library or device

[PeterK]

Originally Posted by SpeedGeek

If you can produce such excellent and awesome code when drunk imagine what you could do sober!

.... then I'm just finding the bugs ...

@matthey and gulliver

Thanks guys. This library is complete in terms of independence now, but it is still not finished yet. After the next Aminet release is done I will try to write my own internal PNG decoding function to get rid of the slow detour through the datatype system.

[clauddio]

Originally Posted by PeterK

.... then I'm just finding the bugs ...

@matthey and gulliver

Thanks guys. This library is complete in terms of independence now, but it is still not finished yet. After the next Aminet release is done I will try to write my own internal PNG decoding function to get rid of the slow detour through the datatype system.

that's will be cool because png icons are really slow right now due png datatype
maybe you can make PNG icons more fast than the normal 0S3.5 icons?

[PeterK]

...maybe you can make PNG icons more fast than the normal 0S3.5 icons?

No sorry, I can speed up the PNG decoding, but the icons will still use the OS 3.5+ typical colormapping, and therefore they won't be faster than OS 3.5 icons. Maybe, in a second step, I could add the possibility to draw the truecolor icons directly to the screen as this is done by the PowerIcons patch or AfA_OS, but I don't know when this could be realized??

Btw, If you want more speed then don't used this damned slow DOpus Magellan II. It has its own icon.module and I can't do much for DOpus5 and also don't like it.

[daxb]

Originally Posted by PeterK

Btw, If you want more speed then don't used this damned slow DOpus Magellan II. It has its own icon.module and I can't do much for DOpus5 and also don't like it.

But you could patch the icon.module then you could like it.

[NovaCoder]

Originally Posted by PeterK

Updated to icon.library 46.4.237 (Be careful, this is just a snapshot, a nightly built from a drunken coder)

BTW, the icon.library is now completely based on my own source code. It is finally independent and free of the AmigaOS copyright restrictions.

Well done Peter, a milestone in Amiga development for sure

[Don_Adan]

Originally Posted by PeterK

.... then I'm just finding the bugs ...

@matthey and gulliver

Thanks guys. This library is complete in terms of independence now, but it is still not finished yet. After the next Aminet release is done I will try to write my own internal PNG decoding function to get rid of the slow detour through the datatype system.

Perhaps you can use meynaf's PNG decoding routine. This ASM version is free, but you can write own version, maybe will be better.

[SpeedGeek]

Originally Posted by matthey

Maybe worse. Alcohol releases creativity in studies:

http://www.medicaldaily.com/news/201...vity-study.htm

Undoubtedly, another study conducted by a drunk and sponsored by the alcoholic beverage industry!

[mfilos]

Thanks for the updates Peter my friend! Lotsa kudos \o/
Sorry for not testing these faster (as I normally do) but my daughter recently born 2 weeks ago so I gave all my attention to her and my wifey

I just tried the last version and it works awesome as always! For some reason the test icons on your AllIconsOnWB archive seemed a lot faster (especially the PNG ones).
I also converted an icon via CopyIcon from OS4 format to classic format and from 17KB it reduced to 4.9KB and with a lot greater speed!

Congratz for at LAST getting out of shity copyright Amiga Inc stuff restrictions. I really hope other coders will have your success

/respect

[PeterK]

...my daughter recently born 2 weeks ago...

Congratulations, mfilos
Who has said that Greece has no future ??
You have a lot of sun, you have giros and wine, you have a nice wifey and now you're also the proud father of a little girly, what else do you want ??

For some reason the test icons on your AllIconsOnWB archive seemed a lot faster (especially the PNG ones). I also converted an icon via CopyIcon from OS4 format to classic format and from 17KB it reduced to 4.9KB and with a lot greater speed!

Hmm, I don't know if there is any difference compared to the previous versions, but if it's faster for you now there must be a nice hidden feature, that's ok, of course

@Don_Adan

Perhaps you can use meynaf's PNG decoding routine. This ASM version is free, but you can write own version, maybe will be better.

It's not the biggest problem to build such a PNG decoding routine, since I already have the specification of the PNG file structure and also the source code of the PowerIcon patch from Elena Novaretti. No, it's more the lack of self-motivation to start the job and get it done.

[cosmicfrog]

Peter

[clauddio]

hey peter
how about a new picture.datatype done in ASM ?
the latest one from OS3.9 bb2 is slow
can u try to make it faster?

[PeterK]

...how about a new picture.datatype?

The icon.library is not finished yet. There is still a lot to do.

But, why don't you start coding yourself, clauddio ?? Never say, you couldn't do it, you will learn it by doing and here, at EAB, are many coders who would help you if there is something too difficult. Just try it.

[Bamiga2002]

The latest icon.library v238 seems to eat all my chipram in a heartbeat. I used DISABLEROMMODULES "" as adviced. I even downgraded from newicon.library v45 to v44 but all the same. With v228 no probs.

[PeterK]

Which of your systems is that ? WB 3.1 or WB 3.9 ?
If WB 3.1, is FBlit installed and has it the correct configuration ?

The latest icon.libraries are checking if FBlit is running before they switch to FastMem on WB 3.0/3.1. This was different with 46.4.228, it was always using FastMem as default memory.

If you use WB 3.5, then you can put the command WBCtrl ICONFAST into the startup-sequence just before LoadWB. And WB 3.9 has the Workbench preferences where you can choose FastMem (other memory) for icons.

If really nothing seems to work then try this (I did not check it out yet because my Pizza and Red Wine are waiting)

[Bamiga2002]

Originally Posted by PeterK

Which of your systems is that ? WB 3.1 or WB 3.9 ?
If WB 3.1, is FBlit installed and has it the correct configuration ?

The latest icon.libraries are checking if FBlit is running before they switch to FastMem on WB 3.0/3.1. This was different with 46.4.228, it was always using FastMem as default memory.

If you use WB 3.5, then you can put the command WBCtrl ICONFAST into the startup-sequence just before LoadWB. And WB 3.9 has the Workbench preferences where you can choose FastMem (other memory) for icons.

If really nothing seems to work then try this (I did not check it out yet because my Pizza and Red Wine are waiting)

I'm running OS 3.9, no FBlit but Mediator with Voodoo (see sig). I already had "WBCtrl IMT=ICONFAST" and in Workbench-preferences "Other memory". I also tried IconsToFastmem in place of the WBCtrl-command. Sadly none of these options worked. When WB loads there's 1.5Mb chipram left, as I try to open DOPUS 4, it can't open the screen an instead reverts to 4-color PAL screen (all chipram gone).

EDIT: I also downloaded the new Aminet-release v240, same thing here. I reverted back to v228 for now. And btw. I also have the PowerIcons-patch running.