icon.library 46.4 test versions

[PeterK]

Alright, now I can wait another minute or two for your ACA system.....

I don't know if you can help me. I've tried a couple of jpeg libraries.

I'm still wondering which jpeg.libraries you've tried out before ?
But of course, I'm glad that you could fix it finally

Even if your motherboard has a problem with the colors, that should not be saved in the screenshots from SGrab !!

Thanks Retrofan, I've read it.

[Retrofan]

I'm sure I had tried that library. Surely I had another problem then with the png ones and I used finally another, well now it's ok. Thanks a lot

Originally Posted by PeterK

Even if your motherboard has a problem with the colors, that should not be saved in the screenshots from SGrab !!
.

No, as you can see it hasn't any problems with colors using SGrab, and that's why I want to use it. In real all is blue.

Video with WinUAE booting the cf Hd: [ Show youtube player ]

[PeterK]

Many thanks for your video clip and good luck for repairing your damaged mainboard. I hope that it's only a dead amplifier in the RGB booster or so and nothing broken in one of the bigger chips.

[Retrofan]

PeterK is there a way to remap dual PNG icons to 16 colors (Rebel's palette) using your icon library?

[PeterK]

The icon.library always maps to the closest available colors of the screen. And if all pens are locked by a fixed palette it's not possible for the icon.library to obtain a new free pen. Thus, it has to find the pen with the best matching color out of the fixed palette. That is exacly what happens on your 16 color AmiKit system IMHO.

For 16 color screens or even less a fixed palette will usually work much better than a screen with a few free pens, because the first images that have to be mapped will get their colors and all the rest has to get happy with that selection. The worst is that there will always be some pens left totally unused because the price for a pen gets higher when the number of the remaining free pens comes closer to zero.

[PeterK]

Updateted to icon.library 46.4.253

The internal PNG decoding is done now!

[Bamiga2002]

Good! Is "NoAlpha" env-var still used with this version?

[PeterK]

No, atm the ENV:IconLib46.prefs is not used at all. You can delete it.

But the zlib.library is still required, it's also used by the PNG decoding now!

[Bamiga2002]

Works !
Hmm...did you optimize something or do I just imagine the icon drawing being a little snappier than before?

[Retrofan]

In my Amikit the dual png icons are shown extremely fast .

[mfilos]

Cheers for this work Peter my friend!
I can't wait to test it out myself as well (I was moving house these last 2 weeks)

[PeterK]

Originally Posted by Bamiga2002

Works !
Hmm...did you optimize something or do I just imagine the icon drawing being a little snappier than before?

That's a good one, a nice joke !!

In my Amikit the dual png icons are shown extremely fast

Well Retrofan, and you don't even have to care about choosing the right png.datatype version anymore.

[Retrofan]

Jeje... but (not related) it seems I've got a problem with Workbench2000 and Exec.library
Error "Recoverable" by Exec.library
Hunk..."ROM-exec 40.10 (15.7.93)"
Cause: Memory header not located.

Right not I was searching the "lost" beta exec.library of Cosmos and reading about something related Piru did.

If I get running Workbench2000 (or if not, Amistart), I will have the Amikit conversion for real and slow miggys "full equiped" and ready to be shown working.

Edit: Extrange too why I get the original Amistart of Amikit working, but the colors of the taskbar are garbled and rare, and the icons aren't shown.
ScreenTab works perfectly, and I like that the bar is shown when you put the pointer at the bottom, like in Windows, and later disappears, but the icons are very small, and 8 colors only.

[PeterK]

Originally Posted by Retrofan

Error "Recoverable" by Exec.library
Hunk..."ROM-exec 40.10 (15.7.93)"
Cause: Memory header not located.

Right not I was searching the "lost" beta exec.library of Cosmos and reading about something related Piru did....

Never use one of the patched libraries from Cosmos, because he did not want to accept the Amiga programming rules, thus his libraries may cause conflicts with other software. For example, his exec.library AllocVec() and AllocMem() functions will crash with other patches like my own MemTrailer which is part of AmiKit. But the bug is definately caused by Cosmos' exec.library and not by MemTrailer!

[Retrofan]

Thanks. And the exec44beta4 of Piru? http://www.sintonen.fi/sw/
Not sure if that's an exec.library or what.

Can you tell what should I try? Thanks master.
Edit: And what I edited:

Originally Posted by Retrofan

Edit: Extrange too why I get the original Amistart of Amikit working, but the colors of the taskbar are garbled and rare, and the icons aren't shown.

Do you think it has something to be (and can be improved still) with your library?

[PeterK]

Why do you want to use Piru's exec.library nowadays. He has written it before OS 3.9 and exec.library v45 came out. If you are using OS 3.9 then I would recommend to install the DEVS:AmigaOS ROM Update with SetPatch and you won't need Piru's exec.library v44 anymore.

In general, if you think about installing any patches or other components onto your system you should know exactly what you are doing, what the requirements and the limitations of any patch are. So, please RTFM first and then install only one patch or replace one component at a time and check your system for possible conflicts and problems caused by this single piece of software.

[Retrofan]

Yes, you are true, that's why I preffer to make experiments... in WinUAE. But for what I see now (listen Tony) it (I mean a copy and the real Cf Hd even) hangs when booting in WinUAE.

[PeterK]

why I do get the original Amistart of Amikit working, but the colors of the taskbar are garbled and rare, and the icons aren't shown.

Maybe, I'm just repeating now what I already tried to explain to you before:
AmiStart needs a TrueColor (or HiColor) screen in order to work correctly! If you still don't believe me then please learn to use Enforcer and you will see thousands of hits coming up as soon as you are trying to use AmiStart on any native screen with 256 colors or less. A hit doesn't mean that it crashes or freezes immidiately, but sooner or later these memory trashings will call the Guru.

There is still one difference between your real Amiga and WinUAE:
WinUAE won't emulate floatingpoint exceptions. So, if your system runs on your real Amiga but not on WinUAE then you may still have a problem with software that generates an FPU exception.

[Retrofan]

You are true. It runs without FPU now.
Edit: In WinUAE I've installed BoingBag2. Now I've got the same error/message, but this time Hunk... "Rom-exec 45.20 (6.1.2002)"
I've got also a problem in libs:muimaster.library trying WB2000

Sorry, it will be better to go on by Pm's or to open another thread.

Edit: As you told me it seems Amistart is made for a graphic board.
I believe the problem with Workbench2000 must be the muimaster.library
Reedit: After searching and searching and searching I think I've got the answer. This is the only version that seems to work: http://aminet.net/package/util/wb/WB2000_19
Edit: Yes, this seems to work perfectly well.

[tom256]

Try this muimaster: http://aminet.net/package/dev/mui/muimaster020

For me icon.library works perfect.

Thx PeterK.