icon.library 46.4 test versions

[AMIGASYSTEM]

Originally Posted by PeterK

Maybe the OS 4.1 icons all have correct 4-color planar images with the same size as the ARGB images. Then my library won't replace the planar images by default and AfA has no problems. But many old OS 4.0 icons still have these stupid 256 color pklanar images include which looks terrible wrong without a palette. (I don't have OS 4.1)

You can force the replacement with my option "KillPlanarImages".

I have to add "KillPlanarImages" on startup-sequence of OS 3.9?

[PeterK]

No, you can also call it from a shell window before you convert the icons.

Btw, OS 4.0 has no such problems like AfA_OS, because it reads the ARGB size correctly from the FORM FACE chunk and not from the DiskObject Gadget structure.

[AMIGASYSTEM]

Originally Posted by PeterK

No, you can also call it from a shell window before you convert the icons.

Ok inserted "KillPlanarImages" in Startup-Sequence after the command IPrefs and now the icons Original Icons OS4.1 converts are no longer seen (see screenshot)

Btw, OS 4.0 has no such problems like AfA_OS, because it reads the ARGB size correctly from the FORM FACE chunk and not from the DiskObject Gadget structure.

So the problem is only on the old OS 4.0 icons

[PeterK]

No, the problem is that AfA reads the ARGB image size from the wrong location in the icon. And it also writes the size to the wrong location and destroys icons:
http://eab.abime.net/showthread.php?...51#post1189751

[AMIGASYSTEM]

Yes "resize from AFA Prefs" causes the corruption of the OS4 icons

[PeterK]

Time to go now. It seems that hexaae comes with new bug reports soon ...

[AMIGASYSTEM]

I forgot ... of course, those who use AFA-OS will have no need to manipulate the icons on 3.5/3.9 systems because they can do it comfortably on AFA-OS

[hexaae]

Originally Posted by PeterK

Time to go now. It seems that hexaae comes with new bug reports soon ...

No bugs but I have a question: why SwazInfo on icon image drag'n'drop from another (NI or CI) icon won't save the new icon image on exit? Is there a side-effect in icon.library 46 or was it normal behaviour for SwazInfo..
P.S.
At least SwazInfo finally displays NI/CI icons correctly with WB3.9 thanks to your library...

[AMIGASYSTEM]

Originally Posted by hexaae

No bugs but I have a question: why SwazInfo on icon image drag'n'drop from another (NI or CI) icon won't save the new icon image on exit?

Excuse me hexaae I do not know if I understand correctly, but I have no problem after the drag'n'drop, SwazInfo to me correctly saves the new image OS3.9 Standard that AfA-OS

-------------- Italiano -------------

Scusami hexaae non so se ho capito bene, ma io non ho nessun problema dopo il drag'n'drop, a me SwazInfo salva correttamente la nuova immagine sia su OS3.9 Standard che AfA-OS

[hexaae]

I'm using:
SwazInfo 1.8 (30-Ott-1994)
Copyright ©1993,94 David Swasbrook

icon.library 46.4.490
(68020)

workbench.library 45.132 ( 8-Set-2012)

[PeterK]

Originally Posted by hexaae

No bugs but I have a question: why SwazInfo on icon image drag'n'drop from another (NI or CI) icon won't save the new icon image on exit? Is there a side-effect in icon.library 46 or was it normal behaviour for SwazInfo..
P.S.
At least SwazInfo finally displays NI/CI icons correctly with WB3.9 thanks to your library...

SwazInfo can only handle (display and swap) old planar images, nothing else. If you have a NewIcon, ColorIcon, PNG or OS4 icon my library always returns pointers to the decoded planar representation of these higher formats in the 3.1 DiskObject Gadget structure to the calling program like SwazInfo. So SwazInfo gets something that it is able to display. The pointers to the original planar images are saved internally in the extended OS 3.5 DiskObject structure. The icon.library v45 does the same, but AfA_OS doesn't swap the planar images.

When you save in SwazInfo my library restores the original planar images in the DiskOject Gadget structure like v45, so finally the images didn't change at all. And again AfA doesn't swap anything back here, thus SwazInfo could succesfully replace the old planar images, which look all a bit broken in AfA_OS since it writes some pointers directly into the first bytes of all planar images resulting in some graphics corruption in the first line.

[hexaae]

Sigh… I wish SwazInfo sources would have not been lost so that someone could finally update it to add support for modern icons
(RAWBinfo is too buggy and causes crashes with 110+ tall CI icons on drag'n'drop, and also MuForce hits in some other circumstances. Rubbish IMHO, so the only alternative is SwazInfo, out of date sigh… Std WBInfo() is ok and supports drag'n'drop etc. without crashes or MuForce hits, but doesn't support double-click to quickly comment tooltypes and tooltypes drag'n'drop, like SwazInfo. Have to live with std WBInfo() up to new WB3.1.4 at least )

I need to manipulate Tootlypes often, especially for WHDLoad games where I use custom configs with (e.g.) "ExecutePostDisk=c:uae-configuration cachesize 0 immediate_blits false…."

[PeterK]

As I already said somewhere else, I'm using a combo of SwazInfo and RAWBInfo and never had any real problems with that solution. SwazInfo opens first and I mainly use that for editing the ToolTypes, DefaultTool or icon type, but I can still call the "original function" from the menu to open RAWBInfo, which is better for image swapping and some other things. I never had any real crashes, although RAWBInfo sometimes throws Enforcer hits like reading from address 0, which is harmless. I can drag & drop icons up to 256x256 (please remember that NewIcons have a limit of 93x93). But I'm not a professional bug hunter like you.

[AMIGASYSTEM]

Originally Posted by hexaae

(RAWBinfo is too buggy and causes crashes with 110+ tall CI icons on drag'n'drop, and also MuForce hits in some other circumstances)

[ Show youtube player ]

[hexaae]

@AmigaSystem
Issues of RAWBinfo are well known. Run it with Enforcer/MuForce and you'll see... If you don't believe me try to drag'n'drop this icon image over another icon with RAWBinfo. https://nofile.io/f/V3dWVRFwoUa/BatmanTheMovie.info

[AMIGASYSTEM]

Originally Posted by hexaae

@AmigaSystem
Issues of RAWBinfo are well known. Run it with Enforcer/MuForce and you'll see... If you don't believe me try to drag'n'drop this icon image over another icon with RAWBinfo

Yes, your icon BatmanTheMovie gives me memory problems with RAWBinfo on AFA-OS, it also behaves the same with the drag'n'drop on OS4.1, but the exchange works well if I use CopyIcon,this confirms that the problem is only on "RAWBinfo"

-------- Italiano -------

Si l'icona la tua BatmanTheMovie con mi da problemi di memoria con RAWBinfo su AFA-OS, si comporta uguale anche con il drag'n'drop su OS4.1, ma lo scambio funziona bene se uso CopyIcon, questo conferma che il problema sia solo su "RAWBinfo"

[hexaae]

Originally Posted by AMIGASYSTEM

Yes, your icon BatmanTheMovie gives me memory problems with RAWBinfo on AFA-OS, it also behaves the same with the drag'n'drop on OS4.1, but the exchange works well if I use CopyIcon,this confirms that the problem is only on "RAWBinfo"

-------- Italiano -------

Si l'icona la tua BatmanTheMovie con mi da problemi di memoria con RAWBinfo su AFA-OS, si comporta uguale anche con il drag'n'drop su OS4.1, ma lo scambio funziona bene se uso CopyIcon, questo conferma che il problema sia solo su "RAWBinfo"

Yep, RAWBinfo requires some fixes… Anyway std WBInfo() never fails and gives no issues even with large icons like that.

[PeterK]

Originally Posted by hexaae

@AmigaSystem
Issues of RAWBinfo are well known. Run it with Enforcer/MuForce and you'll see... If you don't believe me try to drag'n'drop this icon image over another icon with RAWBinfo. https://nofile.io/f/V3dWVRFwoUa/BatmanTheMovie.info

Your Batman icon is buggy. ProcessIcon shows 1.2 billion colors for the second image. When I drag & drop it into RAWBInfo the CI image data just gets deleted, but I don't get any Enforcer hits on saving. A planar dot icon remains. CopyIcon has no problems. My icon.library limits the number of colors to 256.

The icon has only 1 IMAG chunk = 1 image. Don't know why ProcessIcon reports 2 images ? That could be a bug in ProcessIcon.

Btw, you can repair this Batman icon with IconEdit.

Ok, now we know that RAWBInfo is buggy, ProcessIcon is buggy, IconEdit is buggy anyway, and all other software in this world is buggy too. Send a bug report to god, what a buggy world is that ??

[hexaae]

What's your problem with bugs? You take it too bad They do exists, as well as betatester figures to find them (usually appreciated by devs as they do the dirty and annoying part of the work while devs can focus on development).
Important thing is to fix them (at least those harmful, hopefully) when found.
As you know AmigaOS classic, without protected memory, can easily crash and that's why it's even more important with it

Naah, there is a lot of software which is not buggy and won't make AmigaOS unstable even after a big uptime.
I'm here to help us all having better software in the end, not to blame anyone, don't get me wrong when I report bugs

P.S:
That Batman icon was generated with PPaint ( http://aminet.net/gfx/ppaint/pio_icon.lha ) … using 128 or 256 colors but probably saved as dual (unselected+selected this would make more that 256 total colors)… have to check this. No I saved it as single Coloricon, strange…

EDIT:
yep, must be a bug of Processicon because I just saved a brush PNG 256 colors from PPaint, and loaded the image through IconEdit. Then saved it as single image icon from IconEdit, and Processicon still reports the same wrong 2nd image data (??), so it's not a bug in pio_icon save format for PPaint and the icon is not buggy/corrupt.

[kolla]

Remember that one of the strongholds of Amiga was that it was so elegant and easy to program for? Yeah. Not so easy anymore, is it, or anyone of us would have smacked together a new WBInfo() replacement within a weekend