icon.library 46.4 test versions

[PeterK]

Originally Posted by hexaae

Thank you for the transparent effect re-implementation

Ok, now I could load a brush with the app-icon. The brush file requester has to be kept open until you return to PPaint, and then you have to click on "Proceed" in the requester, or you won't get anything.

And everything here just works in the same way with my latest icon.library as with the OS iconlib. But there was a color palette bug in #556, probably the RLEjit bug, which was fixed in newer versions.

You already confirmed to use #561, which has no such palette problem, same as #563, which is the current Aminet release. But I know, that the pages of this thread icon.library thread are manipulated by some very bad guys in Germany and that I cannot even rely on that my uploads to Aminet are ever arriving there. This is a very sad world ...

[hexaae]

I have icon.library 46.4.563...

Picasso96API.library 2.407 (27-Feb-2022)
©2021 iComp

emulation.library 41.493 (27-Feb-2022)
©2021 iComp

rtg.library 42.1226 (27-Feb-2022)
©1991-99 A.Kneer T.Abt, ©2017-2018 icomp

[PeterK]

Originally Posted by PeterK

I would need your PPaint_Prefs/ settings like the Startup_1.set and maybe other config files and also the MahjonggTiles icon. Which PPaint and OS version, which WB screen settings?

There is no palette issue here with my configuration and #563, not even with P96 yet, but that may depend on both screen modes and depths, from WB and PPaint, chunky or planar, maybe even P96 and WinUAE (version) and settings.

[hexaae]

Originally Posted by PeterK

There is no palette issue here with my configuration and #563, not even with P96 yet, but that may depend on both screen modes and depths, from WB and PPaint, chunky or planar, maybe even P96 and WinUAE (version) and settings.

Strange as I could reproduce it even on different WB versions...
Anyway, I'll try to set up a minimal HDfile for you to reproduce the issue and send it to you in PM (or maybe we can arrange a connection with Teamviewer so you/me can run your debug tools and try to understand what happens on my system?).

P.S.
Do you have a repository dir where I can download old versions of your iconlib? Maybe I could say WHEN it started...

[PeterK]

I think I know now what you are doing. I've tried the same tests with my icon.library 46.4.563 from the libs/68020 drawer, which is not the TC020 version, but just an outdated library for old systems.

With this old 68020 version I get these wrong colors after switching back to the PPaint screen and clicking on "Proceed" in the brush loading requester. And I can get rid of this issue when I replace the rtg.library with an older one, for example the rtg.library v40.4029 from the Aminet layers.lha package. Btw, you said that the wrong colors are only appearing once and then never again until the next reboot. An icon.library issue should appear with every new brush that you load.
http://aminet.net/package/util/sys/layers

So, please use the TC020 version, which is the default and can simply be copied from libs/icon.library to libs:.

No, I don't have a public repository with all iconlib versions, nor do I ever want to use TeamViewer or similar remote access tools.

[hexaae]

Replacing:
rtg.library 42.1226 (27-Feb-2022)
©1991-99 A.Kneer T.Abt, ©2017-2018 icomp

with old:
rtg.library 40.4029 (26-Ott-2014)
©1991-99 A.Kneer T.Abt

will actually solve this glitch. The problem is it will degrade P96 and disable some of its new features (e.g. screen dragging).
TC020 alone won't fix it: only rtg.library rollback solves this palette glitch (I like old coherent look of dithered pixels while dragging with your 020 iconlib everywhere the TC020 uses alpha which is great on 24bit screens, but rolls back to dithered when draggin the icon over volumes or drag'n'drop toolbars).

This means there's something with iconlib VS new P96. Would you collaborate with them to fix this glitch using newest rtg.library?
There's an official (german) forum too for bug-reports etc.: https://forum.icomp.de/index.php?board/36-p96/
or this thread:http://eab.abime.net/showthread.php?t=105576

[PeterK]

The problem is that I don't own any P96 versions from icomp, nor do they want to get bug-reports from others users, who didn't purchase P96, as Thomas Richter has clearly stated in other threads here at EAB. I just tried to solve problems on some user systems (HDFs), where newer P96 versions were already installed, but on my main WinUAE 4.4, OS 3.9+3.1.4 system I only need P96 v2.1 to be happy. Screen dragging is nice gimmick, but no serious feature for me. Try rtg.library 41.14 (P96 v2.2+ ?), which works. Don't know whether it supports screen dragging already. Or just try out all older rtg.library versions that you still have stored somewhere, because I can't do that. Btw. WinUAE 4.9.x also has some new issues. That's why I still prefer to stay with 4.4.0, which seems to be more reliable.

This rtg.library palette issue seems to occur only when you have at least two different screens open, like WB in TrueColor and another 8-bit screen in chunky mode. It is triggered by SetRGB32() and ReleasePen() and it seems to happen when colors of a non-active screen should be changed (for the first time). My icon.library tries to do that with the delayed color mapping. There is no problem with my direct access to the private data structure of PalExtra as I expected. I can still allocate new free pens and increase the reference counters as usual, if I just disable the call to SetRGB32(), then everthing still works, except that I don't get the desired new colors, so a few pixels show wrong colors, but the screen palette and DOpus5 wallpapers won't get corrupted.

... on AfA_OS, but there I first had a new problem, because all OS 3.5 icons appeared with strange colored frames instead of frameless. Then I switched to an older rtg.library v41.14 and this issue was gone. It looks like another problem of the newer P96 versions ...

[hexaae]

Well, I'm a registered user so if you have a detailed bug-report I could post it there as a user experience bug, reporting your programmer observations...
Luckily I made backups of older versions and found it started with rtg.library from 3.2.2 (3.2.1's rtg.library 42.1106 (26-Dic-2021) had screen dragging and works fine without this glitch).

Here is the history:
...
Changes in release 3.2.2:
- Some programs provide a custom planar bitmap for screens that have a chunky pixel
format. In such a case, P96 already created a chunky side bitmap into which such
programs are then silently rendering instead. Unfortunately, BltBitMap() did not
correctly derive the type of this side bitmap, and instead used the type of the
original bitmap instead.
- Mode coercion could have returned a mode ID that does not exist, thus confusing
intuition. The new code is now more careful creating a useful modeID from coercion.
- Sprite colors are now switched if the sprite travels from one screen to another in
a split-screen environment. This does not depend on any particular hardware feature,
but is provided for all graphic cards.
- Fixed passing in the wrong modulo value for the planar BltMaskBitMap() function if
the source bitmap is interleaved. This broke only masked blitting on bitmaps with
the Native driver.
- In case a screen switch to a planar screen with bit depth 3 or less was made, and
a soft-sprite was used on the target mode, P96 might have forgotten to initialize
the sprite colors correctly.
- The rtg.library did not inform the card special feature hooks in case the screen
split position was updated.
- As result of the above fix, the PicassoIV memory and video windows no longer need
to be deactivated if screen splitting become active. They pan now together with the
front screen. Note that P96 currently does not support video or memory windows on
the back screen.

[PeterK]

I can't say more than I already tried to explain in my previous post. There seems to be a problem with SetRGB32() and ReleasePen() on non-active chunky screens (see above). I could work around it in most cases for DOpus5 by suppressing the color mapping on non-active screens, but I did not change this code for other tasks like PPaint, because it could result in other unexpected side effects, if I would do that for every task. SetRGB32() and ReleasePen() are OS functions of graphics.library, and they were not patched by other programs.

[hexaae]

Ok I'll open a bug-report pointing to this thread, let's see if iCOMP can fix it...

[PeterK]

Thanks hexaae!

Btw, my co-editors from the German BND (blöd, naiv, doof) have messed up the status of the green "Online"-LED somehow on their emulated EAB server!

After I've logged out successfully from EAB at 14:17 with the confirmation by the requester "All cookies cleared ...", the name at the top of the page disappeared, but the green "Online"-LED was still on. The status was "last visited Today 14:17". This didn't change after a browser refresh or a complete reloading of this faked page.
Then I logged in again, getting "last visit: Today at 14:17", but now the LED is in "Offline" status, although I'm online and my user name appears!

[Retrofan]

Hi!
Excuse me, Peter. It's been a time, so I haven't tried your latest updates.
The thing is that I love the option that you have in your version 46.4.552 (LD020) that allows you to change an icon while using AGA as it won't change it's version to 3.5, so it keeps TrueColor icons as they are.
Now I've installed your 563 version and I don't see any version of that library that allows you to keep their original format like the LD020 was doing.

Edit: Sorry, I had to try it a bit more.
Now I see that you have a version outside of the 68000 and 68020 drawers, and that's the one that keeps the TrueColors icons.
Thanks, and sorry for the questions.

[hexaae]

@PeterK
Sorry if return on this topic (and for my volatile memory ), but would be possible to add raw pixel dithered dragging (as when it changes at the border of the screen) instead of alpha dragging for TC020? To keep it always coherent

[PeterK]

Originally Posted by Retrofan

Now I've installed your 563 version and I don't see any version of that library that allows you to keep their original format like the LD020 was doing.

Edit: Sorry, I had to try it a bit more.
Now I see that you have a version outside of the 68000 and 68020 drawers, and that's the one that keeps the TrueColors icons.

Sorry, it's not easy to make everybody happy. Whatever I try to simplify the installation, just 10 or 20 % will like it, because it's as they need it, but the rest won't understand it. And none of them ever reads the IconLib.guide. The other special versions are all stored in the bonus drawer.

I've removed the name extensions _TC020, _68020 and _68000 and put them into separate drawers, with the TrueColor version as the new default stored as libs/icon.library, because OS 3.2 users need that, since the old v46.4 is not accepted any longer by the new OS, and it is outdated anyway.

So, on most 020+ systems you can simply copy libs/icon.library to Libs:. This is the TC020 version and it has a lot of improvements in comparison with the old 680x0 versions, although it won't need a gfx-card and still supports all screen modes.

[PeterK]

Originally Posted by hexaae

@PeterK
Sorry if return on this topic (and for my volatile memory ), but would be possible to add raw pixel dithered dragging (as when it changes at the border of the screen) instead of alpha dragging for TC020? To keep it always coherent

Everything is possible in programming, but the effort and the necessary additional code should be justified by the improvement that you can achieve. From my point of view it looks more like a step back into the past when icons are dithered with a checkerboard transparency mask. And then there is also the problem that TrueColor icons have an Alpha Channel for the transparency and not a mask. Of course, I could do that in addition, but I can't see any advantage, just some more complex code, less quality and a little speed loss, too. Not everything needs to be consistent, this world is complex.

The reason for the fallback to the old planar rendering at the screen borders is that it would cost a lot more code to cut out the remaining visible parts of the TrueColor images from the full size rectangles, because you cannot draw into the outer space. The existing blitter functions can do that much easier with the planar images.

[hexaae]

Ok... please, consider it a possible feature (checkboard transparency everywhere or alpha everywhere) with a low pri for the future

[hexaae]

The unreadable disk icons look a bit trashed (part of the dithered pixels is not rendered) after you click on them with "icon.library 51.4.563 (TC020)"


Tooltypes for def_disk.info:
Type: OS3.5 Icon
SS: 15000
IT: Disk
BP: 2,2
SZ: NOPOS, NOPOS, w= 43, h= 43
DT: (YES) SYS:System/DiskCopy
CI -Width : 45
CI -Height : 45
CI -Borderless : NO
CI -NumImages : 2
CI1-Transparent: 0
CI1-NumColors : 16
CI2-Transparent: 0
CI2-NumColors : 18
TT: (YES)
NOGHOST

[PeterK]

Yes, things like that can happen (and you may have to live with these issues for a while). It's caused by the delayed RLE decompression. In this case, the dithered transparency mask was built based on the compressed 2. image, which is, of course, smaller than the full size icon image and is located in the lower part of chunky data block. Usually, it will be uncompressed from there to the top of the chunky data block when you select the icon, finally overwriting itself, and a full size mask should be build (the one with the glow effect).

Ok, I can add this issue to my ToDo list, maybe making an exception for "SELECTEDDISABLED" icons for not using the RLEjit. Edit: If the OS needs this mask for the 2. image already before the icon gets selected and DrawIconState() is called, then we have a real problem, because I won't check disks for being readable or not. Then I could only make an exception for all disk icons. But this has no high priority. Atm, no updates are planned, and I really have no damaged disks!

Btw, does the PPaint palette problem still exist with WinUAE 4.4.0 or 4.9.0 and P96 v3.3 ?

[hexaae]

P963.3.0 has some issues with recent WinUAE 4.9.1 so... but as far I can say from my tests it's been solved!

[AMIGASYSTEM]

Hi Peter, what's up !

I wanted to ask you if there is a way to force a closing of an application from Shell, I am talking about AROS x86, but being based on Amiga OS 3.1 maybe there is that shortcut that works on AROS as well.

I am talking about an App that is called Boingiconbar (this version of Aminet does not have the Quit), basically Boingiconbar can be closed with the right mouse button (Quit), but there is no Shell command to do that.

I need this to change the skin without restarting AROS, by not closing the application the images used are in use and therefore I cannot hot-swap them (AmiStart on the other hand I can safely close it).

You can see how Boingiconbar works in this video:


[ Show youtube player ]