PeterK's IconLib Official Thread - Page 9

PeterK · 23 June 2011, 18:32

Back to the icon.library now... 46.4.216 is ready for testing.
Update: http://eab.abime.net/showpost.php?p=...&postcount=167

James · 23 June 2011, 23:02

Quote:

Originally Posted by PeterK

Back to the icon.library now... 46.4.216 is ready for testing.

Working well on WinUAE. Will test on my A1500 next.

NovaCoder · 24 June 2011, 08:03

All of us Classic coders are crazy, everyone knows that already

mfilos · 24 June 2011, 09:38

It works just fine Peter mate. Thanks for the upgrade.

I just have a note:
- If I copy the 68020 version of PNG.datatype into SYS:Classes/Datatypes (I have an ACA630 030 CPU and also 030 emulation under WinUAE) then only the MasonIcons can be shown. Ken's Icons and PowerIcons examples don't show.
- If I copy the 68000 version of PNG.datatypes into SYS:Classes/Datatypes then everything works like a charm!!!

I realized that problem a long time ago (earlier versions as well) keeping always my own PNG.datatype (thought it was a patched one) but now I understood where the problem was!

PeterK · 24 June 2011, 12:14

Hello mfilos,

I've just tried to reproduce your problem with the original png.datatype 44.6 for the 020 under WinUAE with a 030 CPU setting. But it works! All PNG icons are displayed correctly here.

Please don't use utilities like Patch020 for changing some FPU instructions in the executables. This utility sometimes creates broken code (in about 5% of all cases). Please try the original png.datatype 44.6 from Gunther Nikl (but NOT v43 from Cloanto). If that still doesn't work then send me your WinUAE configuration file.

Update: The PNGdt 44.6 guide says:
Note: All versions compiled for >= 68020 do *require* a FPU!

SpeedGeek · 24 June 2011, 18:03

@PeterK
Error parsing tooltypes bug is back again! (46.4.215)

PeterK · 24 June 2011, 22:39

@SpeedGeek

Quote:

Error parsing tooltypes bug is back again! (46.4.215)

Yes indeed, the same problem, but this time caused by a bug in dos.library which seems to trash memory when DeleteVar() cannot find the variable. I expected that DeleteVar() would do nothing in such a case. Wrong assumption!

---------------------------------------------------------------------

This version is based on a total new concept for the datatype handling:

It will only use the PNGdt 44.6 from Gunther Nikl for the PNG image decoding. Why? The PNGdt 44.6 has the best possible quality, is the fastest datatype for PNG icons, it's small in size, has no bugs or memory leaks and it's freeware. The pngalpha.library can be removed from LIBS: and it's much easier to maintain the alpha channel processing in the icon.library.

You can still use your favourite PNG datatype in parallel operation for your picture viewer(s). To make this possible I've created a new "infoPNG" datatype descriptor which is only used by the icon.library for the ".info" files if no other png descriptor is available. However, the icon.library always directs its tasks to the png.datatype.

Update: The PNGdt 44.6 guide says:
Note: All versions compiled for >= 68020 do *require* a FPU!

All you need to do is:
1.) download PNGdt 44.6 from Aminet and
2.) copy the png.datatype for your CPU into the Sys:Classes/Datatypes dir,
....use the 68000 version if you don't have a FPU !
3.) and put my "infoPNG" file into the DEVS

atatypes drawer. That's it.

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

mfilos · 24 June 2011, 23:26

Quote:

Originally Posted by PeterK

Update: The PNGdt 44.6 guide says:
Note: All versions compiled for >= 68020 do *require* a FPU!

Apparently that is the case

Neither my ACA630 nor my clone WinUAE environment use a FPU alas the problem exists

So I guess sticking with the 68000 version is the way to go as it's now

No harm done.
Thanks for the info and the newest version that I will test right now mate \o/

U rox

PeterK · 25 June 2011, 00:47

It's not such a big drawback using the 68000 version as you might think. It's only 1-2% slower as the 68020 version but still about 20% faster than the WarpPNG.datatype. At least for icons, because the png.datatype has much less overhead which is better for small files.

PeterK · 26 June 2011, 22:32

The pngalpha.library has been re-assimilated again for the icon.library 46.4.218, even though I would really prefer to live without it. But unfortunately, I discovered some icons with a fixed background color predefined in the PNG file already which gets in conflict with my method of extracting the alpha information by comparing two different colored instances of the same image. Some of these icons are included in the Crystal_Clear_Amiga collection, but most of them are part of emailware packages. I got only a few of them together with a bugreport. Of course, the installation of the pngalpha.library is still optional as before.

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

mfilos · 26 June 2011, 23:28

Thx Peter my friend.
Indeed there is a difference using pngalpha and not, checking the example icons

Good job \o/

James · 26 June 2011, 23:47

Quote:

Originally Posted by PeterK

The pngalpha.library has been re-assimilated again for the icon.library 46.4.218

Unfortunately this also means the return of the crashes on my WinUAE system...

Quote:

Originally Posted by PeterK

Of course, the installation of the pngalpha.library is still optional as before.

But not when it is needed by other software. Could an environment variable be used to switch its use on or off?

Mad-Matt · 27 June 2011, 00:38

Would it make any difference if png decoding was inserted compiled into icon.lib ? instead of relighing on other png libs/datatypes. Its just seems to be getting messy needing other files. maybe some speed increase possible having icon.lib do the decoding and not having to worry about bugs or support issues in other decoders.

Just a thaught, other then that great work !

PeterK · 27 June 2011, 01:21

Quote:

Originally Posted by James

Unfortunately this also means the return of the crashes on my WinUAE system...

But not when it is needed by other software. Could an environment variable be used to switch its use on or off?

1.) Which other software uses it on your system. Maybe, the pngalpha.library dosn't like multitasking and to be accessed by two programs at the same time? I could add a Forbid()/Permit() pair around the alpha decoding.
2.) Of course, it's possible to disable it with a ENV: variable. No problem.

I will make a test version for you, James.

Update: OK, 46.4.219 is done.
The variable is ENVARC:IconLib46.prefs and must have the contents "NoAlpha", no matter if upper or lower case. But it's checked only once, not again and again for every icon. If this file can't be found or contains something else, then the pngalpha.library will always be loaded.

@Mad-Matt
No sorry, I've no intentions to integrate png decoding. If you really need speed, then just convert the PNG icons with snapshot. That's all you need to do. And there are also AfA_OS and Scalos already doing this job.

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

mfilos · 27 June 2011, 08:52

So if I understand this right...
- No_Forbid version works like any other version you made but you can now Enable or Disable the pngalpha.library via ENVARC:IconLib46.prefs (putting "NoAlpha" declaration)
- Forbid version just disables pngalpha.library no matter what.

I'm I correct is the complete opposite?

PeterK · 27 June 2011, 09:00

No mfilos, Forbid() and Permt() are exec.library functions to disable and enable the multitasking. After Forbid() the pngalpha.library would run without having to fight with other processes for CPU time and without being desturbed by acessing the system resources. Just use the noForbid() version as long as you don't have crashes, freezes or similar. The Forbid() version is only for James ito see if this could fix some problems.

But there might be other reasons than the pngalpha.library responsible for his problems. For example, I've got some recoverable Alerts saying that Limpidclock is causing illagal states for ReleaseSemaphore(). Also a good reason for crashes and freezes. I've already sent a bugreport to the author.

mfilos · 27 June 2011, 09:05

Yeah but your archive contains 2 icon.library files

Which once do we use? (Forbid or No_Forbid)

PeterK · 27 June 2011, 09:10

Be more patient, I'm a little slow in writing my answers. Read my posting above again.

mfilos · 27 June 2011, 09:23

LOL sorry my friend

Everything works just fine. Cheers

PeterK · 27 June 2011, 09:26

Always nice to read that, THANKS for all your testing, mfilos

23 June 2011, 18:32	#161
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Back to the icon.library now... 46.4.216 is ready for testing. Update: http://eab.abime.net/showpost.php?p=...&postcount=167 Last edited by PeterK; 25 June 2011 at 06:24.

24 June 2011, 12:14	#165
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Hello mfilos, I've just tried to reproduce your problem with the original png.datatype 44.6 for the 020 under WinUAE with a 030 CPU setting. But it works! All PNG icons are displayed correctly here. Please don't use utilities like Patch020 for changing some FPU instructions in the executables. This utility sometimes creates broken code (in about 5% of all cases). Please try the original png.datatype 44.6 from Gunther Nikl (but NOT v43 from Cloanto). If that still doesn't work then send me your WinUAE configuration file. Update: The PNGdt 44.6 guide says: Note: *All versions compiled for >= 68020 do require* a FPU!** Last edited by PeterK; 24 June 2011 at 12:33.

27 June 2011, 09:00	#176
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	No mfilos, Forbid() and Permt() are exec.library functions to disable and enable the multitasking. After Forbid() the pngalpha.library would run without having to fight with other processes for CPU time and without being desturbed by acessing the system resources. Just use the noForbid() version as long as you don't have crashes, freezes or similar. The Forbid() version is only for James ito see if this could fix some problems. But there might be other reasons than the pngalpha.library responsible for his problems. For example, I've got some recoverable Alerts saying that Limpidclock is causing illagal states for ReleaseSemaphore(). Also a good reason for crashes and freezes. I've already sent a bugreport to the author. Last edited by PeterK; 27 June 2011 at 09:08.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
C Code without official includes	redblade	Coders. Language	3	20 March 2013 14:05
A new OFFICIAL AmigaOne 500	DDNI	News	49	18 July 2012 16:08
some goodies not in official .dat	thevoice	project.TOSEC (amiga only)	8	11 November 2006 12:35
The Official "Newly Aquired Games" thread	StarEye	project.SPS (was CAPS)	42	24 February 2006 01:33
official - CD32 better than dreamcast	tin	Retrogaming General Discussion	7	16 April 2004 21:43

24 June 2011, 08:03	#163
NovaCoder Registered User Join Date: Sep 2007 Location: Melbourne/Australia Posts: 4,400	All of us Classic coders are crazy, everyone knows that already

24 June 2011, 09:38	#164
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	It works just fine Peter mate. Thanks for the upgrade. I just have a note: - If I copy the 68020 version of PNG.datatype into SYS:Classes/Datatypes (I have an ACA630 030 CPU and also 030 emulation under WinUAE) then only the MasonIcons can be shown. Ken's Icons and PowerIcons examples don't show. - If I copy the 68000 version of PNG.datatypes into SYS:Classes/Datatypes then everything works like a charm!!! I realized that problem a long time ago (earlier versions as well) keeping always my own PNG.datatype (thought it was a patched one) but now I understood where the problem was!

24 June 2011, 18:03	#166
SpeedGeek Moderator Join Date: Dec 2010 Location: Wisconsin USA Age: 60 Posts: 839	@PeterK Error parsing tooltypes bug is back again! (46.4.215)

25 June 2011, 00:47	#169
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	It's not such a big drawback using the 68000 version as you might think. It's only 1-2% slower as the 68020 version but still about 20% faster than the WarpPNG.datatype. At least for icons, because the png.datatype has much less overhead which is better for small files.

26 June 2011, 23:28	#171
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	Thx Peter my friend. Indeed there is a difference using pngalpha and not, checking the example icons Good job \o/

27 June 2011, 00:38	#173
Mad-Matt Longplayer Join Date: Jan 2005 Location: Lincoln / UK Age: 44 Posts: 1,846	Would it make any difference if png decoding was inserted compiled into icon.lib ? instead of relighing on other png libs/datatypes. Its just seems to be getting messy needing other files. maybe some speed increase possible having icon.lib do the decoding and not having to worry about bugs or support issues in other decoders. Just a thaught, other then that great work !

27 June 2011, 08:52	#175
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	So if I understand this right... - No_Forbid version works like any other version you made but you can now Enable or Disable the pngalpha.library via ENVARC:IconLib46.prefs (putting "NoAlpha" declaration) - Forbid version just disables pngalpha.library no matter what. I'm I correct is the complete opposite?

27 June 2011, 09:05	#177
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	Yeah but your archive contains 2 icon.library files Which once do we use? (Forbid or No_Forbid)

27 June 2011, 09:10	#178
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Be more patient, I'm a little slow in writing my answers. Read my posting above again.

27 June 2011, 09:23	#179
mfilos Paranoid Amigoid Join Date: Mar 2008 Location: Athens/Greece Age: 45 Posts: 1,978	LOL sorry my friend Everything works just fine. Cheers

27 June 2011, 09:26	#180
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Always nice to read that, THANKS for all your testing, mfilos

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)