icon.library 46.4 test versions

[Retrofan]

It should be necessary to know the speed difference showing icons with or without it. I don't have a byte saved in chip mem while using cyberbugfix with or without FBlit.

Edit: Without cyberbugfix it changes from 726.992 to 381.512 (Sorry I've edited because I didn't make it right).

[Michael]

OpenWin benchmark.... 1.7 is 05.11.2014, and in icon lib package it's 1.8 dated 04.11.2014
The diff seems to be somehow related to DO5 check. Any ideas ?

[daxb]

The lates I have is V1.8 (04.11.2014). So I guess the date might be wrong.

[PeterK]

Update to icon.library 46.4.428:

Added a new feature to PNG icons with only one image, which will automatically get a second image with a glowing effect now.

[PeterK]

Update to icon.library 46.4.429:

Some small optimizations for the automatic icon glowing effect, which now also works with OS4 icons that don't have a second image. And also a bugfix in the 68000 version for PNG icons without an alpha channel.

[demolition]

Your icon.library seems to be mainly focused on palette modes, but is it also beneficial to use on RTG boards in 24/32 bit modes over the default icon lib?

[PeterK]

Update to icon.library 46.4.430:

Due to a user request at A1k.org I made the selected icon images with the automatic glowing a little bit darker now, lowering all color components by 30 where possible. Check it out and compare the last two versions, please.

Removed icon.library 46.4.430 again because it seems to cause corrupted memory lists!

BTW: My old PC died completely today !
I can't access some parts of the software now.


@demolition

Of course, you can use my icon.library also on any Hi/TrueColor screen, but not in TrueColor and not with an alpha channel, just with 255 colors and simple transparency.

It would need a totally new design of the icon format. Something that is able to support Low- AND HighEnd-systems at the same time and nothing like these other "solutions" which simply cut off the support for AGA screens and all tools and utilities that need the traditional icon formats. But such a general "All-in-One" solution would require lots of memory and would be very slow.

... is it also beneficial to use on RTG boards in 24/32 bit modes over the default icon lib?

Update: If you mean replacing the original icon.library v45.1 ... yes always, there is no good reason to keep using that anymore. Just try it out and get the full package from Aminet (see post 1).

[PeterK]

Update to icon.library 46.4.431:

Fixed the loop counter "underflow" in the code sequence which makes the second icon image darker. The memory error occured with an icon where all pixels disappeared under the glowing border and no color component was left for a darker image.

[trixster]

I've noticed some icon and window corruption whilst using icon.library but only in the top 1/3 of the screen. My systems details are:

1) WB3.1 with a blizkicked 3.1 rom, ClassicWB Lite as the base install, standard 060 library
2) The latest version of FBlit and FText - FBlit set to Include mode (using PeterK's examble fblit.cfg for WB3.1), qsblitpatch enabled and in-line selected
3) piru's exec44 library /edit, actually this might not be installed, can't remember as i'm at work! will check
4) Don_Adan's scsi.library and graphics.library and dos.library
5) workbench.library patched for 3.1 using peterk's patch in the icon library lha.
6) the 060 HSMathlibs
7) MCP (setup in accordance with the fblit.guide), mainly used for solid window moving
7) Newicons enabled
8) Indivision AGA Mk2, Highgfx 1024x768 16 colours
9) Rebel's 16 colour palette using FPalette
10) PowerWindowsNG to allow moving windows outside of the Wb screen area.
11) blazewcp, cmq060, mumove4k and mufastzero

So the corruption only appears in two circumstances: when selecting an icon or when opening a window with newicons, PS icons or glowicons in. The corruption appears for a split second as the icon is selected or when the window is opening and drawing. It does not stay on screen.

The corruption only happens if selecting an icon in the top third of the screen or opening a window which is snapshoted to appear in the top third of the screen.

I've read that WBCtrl and SIMPLEGELS might fix similar corruption in WB3.5 or 3.9 but I dont believe these are options for WB3.1 even with the workbench.library update.

Any thoughts?

I havent actually delved down to see if it's an issue with PowerWindowsNG (i'll try that tonight) or mcp (I don't think it is) so I'm guessing it's a conflict with icon.library and one of the other system settings i have listed above and the indivision's highgfx mode. I don't get any other graphical corruption from the indivision, unlike some other users.

[PeterK]

(using PeterK's example fblit.cfg for WB3.1)

workbench.library patched for 3.1 using peterk's patch

There is a discrepancy, because if you use workbench.library 45.132 now, then you would need the FBlit.cfg file for WB 3.5/3.9, of course. And later maybe add the INLINE-option if not set already.

Newicons enabled

Remove the NewIcons patch and make sure to use Stephan Rupprecht's emulated newicon.library v44 instead of the original.

As you may have read above, my old XP system just died completely a few days ago, thus I cannot test any of my setups with all the different configurations ATM.

[trixster]

Ah, yes, that makes sense, I'll try the 3.5 config. But for the record, the corruption was occurring before upgrading workbench.library to 45.132 as well! In-line is set.

I'll try and record a video of what's happening.

[PeterK]

I don't know if that all works together with ClassicWB LITE ???

Is Scalos 1.2d also installed ?

Try to switch off any Copper color fades in the background, plz.

[trixster]

No copper colour fades, no scalos. I'm certain it's not a problem with your icon.library peter, rather it's a conflict with another patch/setting on my system. Everything else about your icon.library works perfectly and the icons on the adf display correctly.

I've just noticed you recommendation regarding newicons - i'll remove the patch and try the updated library tonight, thanks!

[trixster]

Ok so I've tried the following in turn and none have solved the issue:

Disabling mcp
Disabling fblit and Ftext
Using PeterK's fblit.config for 3.5/3.9
Disabling newicons

Also, should I be using fblit in include or exclude mode? I've always used exclude and have had zero issues with this so far.

So the icon corruption only happens for a split second when deselecting an icon, not when initially selecting it. It only happens around the edge of the icon, where the transparency is, it doesn't happen over the main body of the icon itself.

Here's a quick bad video of what's happening

[ Show youtube player ]

[PeterK]

From what I've seen in your video clip I would say that you have to live with these scratches. Only without using FBlit and loading icons into graphics memory may help to solve this issue but it consumes your ChipMem.

If exlude mode helps then use it !!

[trixster]

Cool, no probs! It's only a very minor issue so I'm happy to live with it, I just thought it might be a common issue with a known fix. I'll keep trying things to see if I can fix it but I'm not disabling FBlit and ftext as wb crawls without them!

[daxb]

You can do: Test Peter`s IconDemo.adf. Disable all patches from S-S, U-S and WB-Startup. Check if with your current system and not Peter`s icon.library the problem stays.

[Pancio]

hello there.
first of all many thx for this peace of software. its amazing

i found a problem which i dont know if where mentioned. every icon looks just great but i can not change icon type in "information" menu. after changing icon type to whatever: tool, project, disk or folder and saving it nothing happend. it gives me all the time folder type icon. i've tryed new icons, png icons, old icons, glow icons. all of them wont change its tool type.
the solution is to change icon.library with the old one. then change tool types and everything else, and then change with a new icon.library again. am i doing something wrong ? i noticed amikit is using this library also and it has the same issue, cant change icon tooltype in icon information menu.
any help apreciate

im using your icon.library on winUAE so basicly i can set all amiga versions. my workbench version is 3.9 with bb4.

ps sorry about my bad english

[Pancio]

ok i must be more specific.
changing the tool type is working. it has a problem with the same directory name as an icon file. example:

i have got folder called "FileMaster" and a folder icon called "FileMaster.info". now im exchanging folder icon "FileMaster.info" with one i like and then using information menu im changing its tooltype to "project" and select the program which it must start in the "FileMaster" folder.
after all i can start filemaster from within the folder with my single icon file which is outside program folder.

i can change it using old icon.libraries but i can not with yours. simply wont change ist tooltype when the same named folder is on the way.

could it be fixed in a near future ? or it is fixed but im doing something wrong ?

regards

[PeterK]

Originally Posted by Pancio

... many thx for this peace of software. its amazing

Thank you, Pancio ! ... yes, only sometimes it's malefiicent.

... changing icon type to whatever: tool, project, disk or folder and saving it nothing happend. it gives me all the time folder type icon.

As long as a directory with the same name already exists my icon.library forces the icon type to folder. You can only change the type to project if you define the default tool entry before saving the icon. Or in all other cases, use a filesystem browser like DOpus4 and segregate the info file from the directory with the same name.