icon.library 46.4 test versions

[Thorham]

Originally Posted by Michael

Is not it simpler to use the old planar format for HAM icons ?
You only need to lock the first primary colours, the rest are just coper offsets.
The old lib worked fine like that. No idea if the current lib can do the same, theoreticaly, if it is not remapping anything, planar data should be transparent to the lib and only effects the screenmode. Those icons will work properly only on HAM screens only so. I had an example set uploaded to aminet a decade ago ;-)

Yeah, I remember doing this years ago with a pre-rendered HAM icon, and it worked if I'm not mistaken. I've indeed seen some HAM icons on Aminet, and some software that converts images to HAM icons (crappy quality, unfortunately).

Originally Posted by PeterK

I'm not sure if the Workbench is able to blit HAM images onto a HAM screen at all. I would recommend to check that first and to see how to handle PlanePick and PlaneOnOff if it's possible.

Update: I've just checked out with MUIScreenmode what the limitations for a PAL HiRes Interlaced screen with the HAM option enabled are:

This "HAM screenmode" supports only 64 colors and not 4096! Even in LowRes it's not more than 64 colors. And a HAM8 option is not available. Project done ...

Actually, it shows the number of palette colors. 16=HAM6 and 64=HAM8. Trust me, this works. I've seen it work.

Perhaps it's a better idea to pre-render icon sets to HAM, and be done with it. For that to work properly, icon remapping needs to be turned off somehow.

[PeterK]

Ok, maybe you're right.
I've switched frpm AGA to ECS and now HAM supports only LowRes with 16 colors.
Nevertheless, check out if HAM in the image structure is possible or not and how it works, before you are wasting your time.

[Thorham]

Originally Posted by PeterK

Ok, maybe you're right.
I've switched frpm AGA to ECS and now HAM supports only LowRes with 16 colors.
Nevertheless, check out if HAM in the image structure is possible or not and how it works, before you are wasting your time.

Just checked this again with Ham-Icons from Aminet. Works properly with your library, actually. Perhaps it's a much better idea to try and make a proper HAM icon set instead of coding something while it's not needed.

[PeterK]

Yeah, just downloaded the same iconset from Aminet when you posted your suggestion to try it out. Seems to work, indeed
So, HAM in an image structure must be possible, and you can take the challenge to code it if you like!

[Thorham]

There's a problem with using a HAM Workbench. Some programs that open a screen just display a blank screen. What a pity. Would've been nice to have a cool Linux icon set in HAM

At least we didn't waste time writing code for this

[Michael]

IMHO, since we can only use the primary colours in HAM modes, you need to lock the rest of the colours to a single colour (eg. black) then the unaware tools will be unable to allocate pens that do not exist in HAM. A HAM6 wb is very fast on AGA machines, since it is like a 64 colour screen (only 6 bit planes) You have 16 primary colours and a full palette of 4096.

[Thorham]

Originally Posted by Michael

IMHO, since we can only use the primary colours in HAM modes, you need to lock the rest of the colours to a single colour (eg. black) then the unaware tools will be unable to allocate pens that do not exist in HAM.

Is that really the problem? If those applications get pens that are HAM color modifiers, then you should at least see something. Instead, the screen stays entirely blank. Also, and that's almost worse, with only the four standard WB palette colors, HAM becomes quite ugly Makes you wish it was easy to do a WB replacement that uses HAM properly, but it undoubtedly isn't (unless you make one that's incompatible).

Originally Posted by Michael

A HAM5 wb is very fast on AGA machines, since it is like a 64 colour screen (only 6 bit planes) You have 16 primary colours and a full palette of 4096.

HAM5?

[Michael]

Should have been HAM6, and you have 16 colours, 4 WB, 4 MWB, 8 free that need to be locked to some mid RGB colours to minimize HAM ramping.
Sadly you don't get any free pens for progs that require them, and if such a prog chooses black or any other colour (from the upper pallet) it will be black, since you can't shift black to a colour. Something like that.
Also a lot depends on picture.datatype you use, it influences a lot of system things.

[Retrofan]

Just a noob question: If I do change all the def icons and I do have DefIcons in the WBStartup, will all of the already existing will be changed after a reboot or is it just for the new created?

I could of course just try, but I've got all of the screen full of copyicons that I don't want to lose.

Edit: I told I was using 10 CopyIcons at the same time but nope, it was around 20, not a single space on the screen without them apart of the opened windows. Amazing how my AK version can handle with the chip ram and all of the screen full of working windows and IconEdit running on it's own screen too.

[PeterK]

@Retrofan

Hmm, perhaps I don't understand you, but it sounds like a very strange question or how should I call it?

What do you mean with the "new created" icons?
A deficon is just displayed where no real icon exists, but it won't create a new icon on the disk.

Of course, all files without icons will get the new deficon images on the screen after a reboot. Icons that you have changed with CopyIcon before the reboot are real icons and won't be replaced by deficon images anymore.

[Retrofan]

Thanks PeterK. Maybe my question was confusing but you answer what I needed to know.

I have finished my 16C Ken's Icons pack for AK Real and in a couple of hours I will send you an email (Edit: sent), another to Ken Lester who helped me and also a PM to daxb and Michael to try it... I would like some review and an speed test .

Edit. Well, PeterK knows all the story, but maybe the rest want to know. Some time ago I found in my AmiKit Real distro that using 16 colors the Ken's icons it originally uses weren't looking as nice as I could wish using RebelCD32's palette (they were grey), so I asked PeterK for help with that and he made a new improved palette that shows Blue also in those icons. He later included it in his icon.library on Aminet. Using his FPPrefs as a base I've made a palette to make these icons.

EDIT: PeterK has given me some advice to improve them so I will try so. I will start again from scratch as the palette wasn't used for the batch process.

[Michael]

@Retrofan:

Yes, the icon packs refer to Gi. And they are not 32c, they were condensed so they do have their unique 32c or less pallets, the original pallet was 64c (or we can call it globally shared between all the icons).

Your current conversion is actually 32c unique colours per icon. So on a low end system it will not help much in terms of colour presentation.

Speed results for the Prefs dir:
(Converted v Original)
16bit CGX - 0.46s v 0.82s
64c AGA - 1.14s v 1.54s

So the speed improvident is noticeable, probably more on slower system.

The other things...
Amiga Style guide, all icons must be in (info) lower case XXxxxxXXXxx.info
It would be nice to unsnapshot them all, currently a lot overlay each other.

So imho, for lower end systems a screen of 64c is minimum and maximum if you are to use these icons sets. But they should be remapped to a global pallet, then it will look nice and be fairly fast.

Using Rebels 16c is possible, but that will degrade the look considerably.

[Retrofan]

Originally Posted by Michael

Speed results for the Prefs dir:
(Converted v Original)
16bit CGX - 0.46s v 0.82s
64c AGA - 1.14s v 1.54s

So the speed improvident is noticeable, probably more on slower system.

Thanks Michael. Remember also that they aren't using either the 3.5 format. I will add a tool to convert them all to that format too (or I will make it before), so the speed improvement will be even more.

And yes, the set of icons I sent you is meant to be used with at least 32, preferably 64 (the one I use) or more colors as it's done with a 256C palette.

Originally Posted by Michael

It would be nice to unsnapshot them all, currently a lot overlay each other.

Remember this isn't an "Icons Pack" the style of Ken's Icons. The Lzx with all of the icons will be used for the script to install them all, and later Magellan will take care of their positions.

About using a 16C palette I'm thinking in making a set for users that only want/can use 16 colors. I'm thinking (finally) in using dithering. But as I haven't found a nice program with Batch process using a custom palette and dithering with png's and that also keeps the transparency, I will have to make them one by one in the pc (twice as they are dual pngs) and one by one in the amiga changing both images of each icon.

Michael I will send you the pack once finished and with the 3.5 format included to test the speed improvement. Thanks a lot.

[PeterK]

Update to icon.library 46.4.391:

Some fixes in the gfx-patch used by DOpus5 and the WB 3.0/3.1 for the direct drawing. (AGA, OS 3.5+ and the 68000 version are not affected)

Ok, revised version attached again (icon dragging bug fixed).

[Retrofan]

I'll try it ASAP, I'm still converting icons...

I want to share something about the size when you convert the icons to the 3.5 format. Remember I told to Michael I had to convert them still to that format and then they may be even faster.

This was the speed test he made:

Originally Posted by Michael

@Retrofan:

Speed results for the Prefs dir:
(Converted v Original)
16bit CGX - 0.46s v 0.82s
64c AGA - 1.14s v 1.54s

I've got it all almost finished. Compare the sizes with the now converted:

http://hostthenpost.org/uploads/bf1b...5e77ab6b35.png

Around 12M Vs 7M now with the 3.5 format, the original set 15M bytes.

I think that if you use enough colors, like 64 it is better to use a 256 colors palette like I am using in the second set (my installer has two different ones). Just my opinion.
My wife says that she can not tell any difference between the original icons and the ones with the 256C palette while using 64 colors. That's enough for me, but I like/want reviews. Remember anyway that I can not be making a new set of icons for every taste, they take a looot of hours (days), that's why I have been messaging with Ken Lester and lately with Peter (thanks for your patience and support).

As I've seen, the Glow icons of CWB do use 32 colors, just for the info. They (CWB icons) run fast using 16 colors in a slow system (please use at least an accelerator). For AK Real I would recommend to try using at least 32 colors with these new Ken's icons that are dual PNG's. If it is too slow, there is another icon set for just 16 colors, dithered and with a 16C palette, but it looks more pixelated.

Michael (maybe we should talk by Pm) you've said:

Originally Posted by Michael

@Retrofan:

Yes, the icon packs refer to Gi. And they are not 32c, they were condensed so they do have their unique 32c or less pallets, the original pallet was 64c (or we can call it globally shared between all the icons).

Your current conversion is actually 32c unique colours per icon. So on a low end system it will not help much in terms of colour presentation.

I don't understand you. I open the info files with ImageStudio and the Glow icons you talk (you are answering to a PM here) are using 32 colors, so I don't know why you say they aren't. Ok about the palette they used, no idea, they could use whatever amount, but they keep being using 32 colors of the palette of 64 colors or whatever.

About the conversion I sent you is using only 16 colors per icon, but from a 256C palette. In terms of presentation that means that you can not use only 16 colors, but that you need more. If you try you'll see that with a screeen mode of 64 colors, using these 16C icons they look just like if you were using 256, at least if you use PeterK's FPPrefs. I`ve made the second option for just 16C in the case that you can only use 16 colors so they look a bit better, but pixelated.

The best way (how the icons look better) using only 16 colors keeps being using the original icons, although they are slow for slow amigas.

[Michael]

Originally Posted by PeterK

Update to icon.library 46.4.391:

Some fixes in the gfx-patch used by DOpus5 and the WB 3.0/3.1 for the direct drawing. (AGA, OS 3.5+ and the 68000 version are not affected)

Ok, revised version attached again (icon dragging bug fixed).

Looks like you have fixed the icon position shift in DO Info.
But now, icon dragging in DO is broken.
For me, my default drawer icon (blue folder Gi) is effected a lot!
Looks like random dither (background colour) or sometimes even missing blocks. What's even funnier, make 10 drawers in ram, and try dragging them,
all icons apart 1 are corrupt in some way and look different. (sorry, no easy way to grab a test pic in drag mode)

[PeterK]

Originally Posted by Michael

Looks like you have fixed the icon position shift in DO Info.
But now, icon dragging in DO is broken.

Yes, icon shift in DO-Info is fixed, but DO-Info has a huge mem-leak (about 140 kB get lost after every click). But that's not my bug.

The dragging has already been fixed and 46.4.391 was re-uploaded:

Ok, revised version attached again (icon dragging bug fixed).

Please, try it again ...

[Michael]

Originally Posted by PeterK

Yes, icon shift in DO-Info is fixed, but DO-Info has a huge mem-leak (about 140 kB get lost after every click). But that's not my bug.

The dragging has already been fixed and 46.4.391 was re-uploaded:

Please, try it again ...

Mem leek.... That's something new ;-) Have not noticed this before (I guess a more then usual available memory has made me reluctant to noticing memory losses)

And the dragging is not fixed, it broken badly. But worked fine before (I think ;-) )

[PeterK]

Hi Michael,

Update: Ok, DOpus5 icon dragging bug confirmed. It happens when "Use custom drag routines" is disabled in icon settings. And it was already broken since 46.4.389, since introducing the delayed mapping for DOpus5.

[Michael]

Originally Posted by PeterK

DO-Info has a huge mem-leak (about 140 kB get lost after every click). But that's not my bug.

Works fine for me here, no big mem loses. Only first time when the module is loaded to ram. Then nothing, all gets released after use.

But I have noticed another thing, in WB no chip is used what so ever,
but under DO each icon seems to eat away around 500 bytes of chip ram.
Am I missing out on something ?