icon.library 46.4 test versions

[PeterK]

Originally Posted by BigFan

No bashing, i'm still a big fan of your incredible speedy library

Bugreports or feature requests (and big fans) are always welcome and I don't regard them as bashing. Thanks a lot for your feedback !

but it misses some features like alpha-blending (shh) and dithering ....
Attached pic shows same problem here, the banding isn't that obvious, .... Low res (800*600 or less) is completely opposite. banding get's annoying.

Confirmed ! Just compared the def_drawer.info from Ken's v3 and v4 set on a 800x600 screen. V3 has dithered OS 3.5 images and looks good. V4 is truecolor with alpha blending and is color reduced on the fly by my icon.library with the alpha blending converted into just two levels of merging with gray before total transparency is used. This is a compromise, of course, to make the conversion as fast as possible. And as you've already noticed the resulting quality is sufficient for higher resolutions.

I've never tried out any fast dithering algorithms to improve the quality and to get rid of the color bands that you can see in your example. I've no intentions to introduce the alpha blending support in my library, but maybe I can find some fast dithering code. Apart from that I would recommend to use the v3 iconset.

[PeterK]

Originally Posted by vxm

I noticed a different behavior depending on the version of the workbench.library:

- Original release: displaying PNG icon homemade seems to use 16 colors
- With your modified version, displaying PNG icon homemade seems to use 256 colors.

That could mean that it's just a problem of the correct timing.
Try to load the driver DEVS:monitors/uaegfx earlier in your startup-sequence and try out if something changes when you add a line Wait 2 above IPrefs or above LoadWB.

The problem is that my icon.library just checks once at booting if the cybergraphics.library can be opened and then never aigain.

[SpeedGeek]

@ PeterK

If you try to make icon.library do everything you end up with bloatware which does nothing well. (Most of us already have bloatware running on our PCs and we escape to our Amiga's whenever possible because of it).

I would prefer to see a simple icon.library which supports Standard Icons, New Icons and Glow Icons. As far as I'm concerned Power Icons, PNG Icons, 32 Bit Icons, Alpha blending and the kitchen sink are best suited for an iconsupport.library coding project.

[Turran]

Have to agree with SpeedGeek. Toss out a small final we can put in our roms and forget about updating =)

[PeterK]

No SpeedGeek,
I don't want to make my icon.library bloatware. But I will give every feature request at least a chance and check out what's possible and if the required effort is really worth the trouble. If the additional code is not passably proportionated to the improvement that the new feature achieves then I won't realize it.

Just for comparison:
the icon.library v45.1 is 45 kB
my icon.library v46.4 is 29 kB
the PowerIcons patch is 81 kB

... and I've not completely done all possible code optimization in the zlib routine yet. The remaining tweaks won't make the decompression much faster anymore, but maybe I could reduce the size by another few hundred bytes, because I also don't like bloatware like you do

@Turran
If you don't miss any new feature and are happy with the current state then build your ROM and never look for any updates of this library in the future or just ignore them, because perfect things can't be made better

[PeterK]

For BigFan:

Update to icon.library 46.4.319 (experimental)

The color reduction from truecolor to the OS 3.5 format has been improved a little. This should make color banding effects less visible on low resolution screens. This is not done by a complex dithering procedure but simply by pushing the brightness level of every second pixel just a bit up.

[vxm]

"Try to load the driver DEVS:monitors/uaegfx earlier in your startup-sequence and try out if something changes when you add a line Wait 2 above IPrefs or above LoadWB."
I moved the load monitor command after the ENV assign command. No change. Same with the wait command.

"That could mean that it's just a problem of the correct timing.
The problem is that my icon.library just checks once at booting if the cybergraphics.library can be opened and then never again."
Do you think a solution would be possible?

Thanks for your support.

@SpeedGeek
Why then you're posting here. Thats what icon.lib 45.x (OS 3.9) is doing already.

No one wants bloated stuff, Peters icon.lib got all features included yet. It's mere a question on how to process color remapping including my suggestions.

It's far too late now, i'm tired and before start talking gibberish:


couldn't resist to check out the new version, does a bit better. See below.
And now time to

[PeterK]

Update to icon.library 46.4.321 for BigFan (experimental)

A few more modifications since 46.4.319. The RGB levels are now pushed up by 331 only instead of 444. With the 444 it was already producing stripes. The code for repeating pixels with the same color has been removed for obvious reason.

I regret that I cannot use some real dithering code with error difusion but adding such an algorithm to my color reduction would make very slow. On the other side, this small RGB level modification has sometimes already a very simple dithering effect.

[Bamiga2002]

I appreciate every effort you make towards a better icon.library
Will continue testing new icon-libraries even if it's good for my purposes already

[SpeedGeek]

@BigFan

I'm satisfied with PeterK's efforts to keep the code to a reasonable size despite the many new feature requests.

[PeterK]

@SpeedGeek
BigFan's request for dithering and my effort to implement the simplest possible type of something like dithering requires just 20 additional bytes atm. That's micro-bloatware !

@vxm
You said that you've tried two differnt versions of workbench.library. Which one? Are SetPrefs, IPrefs (don't use FastIPrefs), LoadWB and Prefs/Screenmode all v44+ ? You can NOT merge files from v40 and v44+. You can also try out my P96 setup from WinUAE. It works with all wb.libs. But, of course, I've never tested it with E-UAE.

[vxm]

All my testes were made ​​only with OS 3.1. And yes, I lazily (yes I know, sorry) replaced workench.library v3.1 by your worbench.library v45.132.

Nevertheless, it seems that there is a problem with OS 3.1 and E-UAE. However, I promise to install the OS 3.9 and and test it with your library.

[Retrofan]

Originally Posted by PeterK

@SpeedGeek
BigFan's request for dithering and my effort to implement the simplest possible type of something like dithering requires just 20 additional bytes atm. That's micro-bloatware !

Impressive, finally you will put everything in 1k Lol.

Tried 46.4.321 and looks great with 256 colors.

But (and I'm sorry now I don't know since what version) with 16 colors Ken's icons need more blue I believe.

[Thorham]

While trying your library, I found it annoying to have to make it resident for Kickstart 3.0 so I wrote a little hack that allows loading the library during the startup-sequence without it being made resident and without causing a reboot because of it.

It works by renaming your icon.library to something else, opening this new library and the icon.library in ROM and then swapping the name pointers in the libnode structure. Yeah, dirty, I know, but it works! Just run it right after setpatch.

Note that I also changed the name in the library file, or it won't open (but you knew that already).

Here's the hack:

	incdir	"asminc:"

	include	"exec/exec.i"
	include	"lvo/exec_lib.i"

start
	move.l	4,a6

	lea	_oldIconLib,a1
	clr.l	d0
	jsr	_LVOOpenLibrary(a6)
	move.l	d0,a2

	lea	_newIconLib,a1
	clr.l	d0
	jsr	_LVOOpenLibrary(a6)
	move.l	d0,a3

	move.l	LN_NAME(a2),a4	; old lib name
	move.l	LN_NAME(a3),a5	; new lib name

	move.l	a5,LN_NAME(a2)	; ugly swap
	move.l	a4,LN_NAME(a3)	; names hack =)

	clr.l	d0
	rts

_oldIconLib
	dc.b	"icon.library",0
	even

_newIconLib
	dc.b	"abcd.library",0
	even

While trying your library both with the resident method and my hack, I discovered that using it with MCP makes the system crash. I'll try to figure out if it's just one of MCP's options or the whole program.

[mfilos]

It's surely some option as I run MCP just fine on my OS3.9 setup with the newest icon.library and a LOT of other newer modules as well

[daxb]

Maybe AppIcon, AppChange, Virtual Icons, No Iconborder or Library Search. Or nothing of that.

[Thorham]

New Tool Types caused the problem on my setup (what does that even do ). Fabulous, now I can use the library!

Thanks PeterK, this library works great

[PeterK]

Originally Posted by vxm

All my testes were made ​​only with OS 3.1. And yes, I lazily (yes I know, sorry) replaced workench.library v3.1 by your worbench.library v45.132. ....
However, I promise to install the OS 3.9 and and test it with your library.

For wblib v45.132 you will need LoadWB v45. And IPrefs should be from the same OS version as all the setup tools in Sys:Prefs. IPrefs v40 can NOT read ENV:Sys/#?.prefs from OS 3.5+. If you use SetPatch v44+ then you won't need LoadModule or LoadResident and it's indeed not recommended to use these tools when IPrefs is v44+.

@Thorham
Thanks a lot for your iconlib loader ! It's nothing dirty with your hack, renaming the existing library is ok. I did the same once with the mathlibs and made an all in one patch for the 4 IEEE mathlibs. You can still find some similar example in my MathLibsUAE/bonus/badcode/PatchMSBmad.asm. I will have a deeper look into your loader code ASAP.

Which "New Tool Types" ? Is that an MCP option? I don't use MCP (the master crash program).

[PeterK]

Originally Posted by daxb

Maybe AppIcon, AppChange, Virtual Icons, No Iconborder or Library Search. Or nothing of that.

Same question here: are that MCP options or what is the relation to my library?