icon.library 46.4 test versions

[Amiga68k]

Originally Posted by daxb

With RTG you can have 16 or 24 bit screens what should deliver enough pens for everything.

Now you got me confused again... because whether I choose 8, 16 or 32 bit screens, the amount of 'shareable pens' stays at 256...

[PeterK]

RTG screens have lots of colors (up to 16 million) but no screen on the Amiga can have more than 256 pens. The advantage of RTG screens is that some image viewers, picture datatypes and applications can use these colors directly by accessing the gfx card hardware through cybergraphics.library. So they won't need to allocate any pens (ie. for the background picture). In that way more free pens are remaining for other applications which have no direct support for RTG like DOpus 4. The pens are always mapping to any of the screens colors, but the palette is limited to 256 colors.

Update to icon.library 46.4.462:

Tried to make ReleasePens possible again in those cases which don't lead to DOpus5 crashes during screenmode switches. No idea if this could result in better colors or not.

[Michael]

Some more test....

462 does not release any pens here on closing windows with icons that were just taken

Done some tests with 457 under CGX, P96 and AGA and enforcer very early in startup
Found a problem with one of MCP guruhistory options (not too dangerous, but still two bad long reads)
Changing screenmodes in any possible combination, no hits.
The only time I managed to get hits was when I disabled RTG support completely
and had only default PAL monitor available. But I am not sure that this is caused by icon lib since pure PAL requires a lot of other system tuning options switched.

[daxb]

Originally Posted by PeterK

RTG screens have lots of colors (up to 16 million) but no screen on the Amiga can have more than 256 pens. The advantage of RTG screens is that some image viewers, picture datatypes and applications can use these colors directly by accessing the gfx card hardware through cybergraphics.library. So they won't need to allocate any pens (ie. for the background picture). In that way more free pens are remaining for other applications which have no direct support for RTG like DOpus 4. The pens are always mapping to any of the screens colors, but the palette is limited to 256 colors.

Now I'm confused. I don't understand the limitation of max 256 pens on Amiga screen when using RTG. Where does the limit come from? How do I notice it in practise? FullPalette will stay by 256 pens, right? I thought other color pic stuff is done by a color wheel or similar where you can choose all 16 or 24 bit colors. Need some clarification.

[Michael]

You can select any of 16M colours on AGA or Modern RTG (Old RTG had limits of 6bits per colour, you monitor might still be limited to 6bits per RGB, most cheap LCDs even today!)
Now you have a palette of 256 pens that you can assign any colour that is required by your software, and it can then change this pen if required at any time. This is very similar to pallet based 8bit screens. The only advantage of HiColour screens, is you can use direct drawing to display any colour at any time, but you can't modify it after. But you can modify any of the 256 pens and they wil change everywhere on screen, where they are in use. By the way, windows defined only 16c in the past, the rest was a locked palette for dithering.

[PeterK]

Originally Posted by daxb

Now I'm confused. I don't understand the limitation of max 256 pens on Amiga screen when using RTG. Where does the limit come from?

A pen is a color register in the Amiga graphics chipset. AGA has 256 color registers which can hold 24 bit RGB values, and OCS/ECS have only 16 color registers which can store 12 bit RGB and there is an EHB flag somewhere. Using the chipset means maximal 256 colors out of 16 million for AGA or 16 (32 with EHB) colors out of 4096 for OCS/ECS.

On a gfx card you can access the 15/16/24 bit RGB values (+alpha channel byte?) of every pixel directly with Read/WritePixelArray() if your software allows that.

@Michael
Releasing pens is only possible on WB screens as long as DOpus5 has not been started. If DOpus shares the same screen with WB it will always push up the pen reference counters only so that not even WB can reduce these shared counters to zero again in order to set the pens free.

Whenever a Guru can't be displayed anymore by the system it stores the Guru number in address $100 and writes "Help" into address $0. After a reboot it grabs the Guru number from $100 then and displays it. Maybe MCP's Guru history patch tries to get this information, too, but reading from $0 or $100 throws Enforcer hits as I've just learned a week ago.

[Michael]

Just made another round of tests with 460 under CGX/RTG and P96/RTG at 16 bits (open/close window with many icons)
DO5 in WBR - works fine, pens released
WB on DO5 screen! - works fine, pens released
WB - works fine, pens released
DO5 on WB - works fine, pens released
WB + DO5 custom screen - also works, pens released

[AGS]

In my opinion its hard work to code something that functions under all circumstances an Amiga system can encounter. Its much easier to rely on the nowadays standard that one has truecolor and chunkypixels. In the late days one big reason for the trouble commodore went in in th 90s was that Jay Miner and the others did not foresee the reality of a 24 bit pixel and did not think about alphachannels and such. Or did they? If they had left open some space in the custom chip registers for future 24 bit technology, things had developed not so bad. Was this impossible? What do you think?

[Michael]

Finally, got a hit!

But from IPrefs

And really I was asking for it, since it really got confused as to what I am doing

So.... WB, DO5 custom screen, and DO5 on WB! (You get a warning doing so!)

Anyway, screenmode switching works for WB+DO5 simultaneously, pens are released for WB, DO5 and DO5 custom, all running fine, no confusion as to what task holds what.

[Michael]

Originally Posted by AGS

...and the others did not foresee the reality of a 24 bit pixel and did not think about alphachannels and such. Or did they?

They did, OS 3.1 is a move to RTG, there was development of 24bit, they made their own RTG boards, close cooperation with 3rd parties like DRACO systems that are fully RTG, and there were even some 3D plans. The problem is top management and other business decisions and outside influences that screwed a lot of thing up. It's amazing how a 1990's idea has held up and was expandable and still is.

[AGS]

I can remember some screenshot in an old Amiga magazine that read something with "RTG" below it and there were very nice soft bordered cycle gadgets with circle-like shaped symbols at the left. I felt that was something magic and never really saw that GUI elsewhere.

[PeterK]

@Michael

You're telling me that everything works fine with 460, releasing pens and screenmode switches. But are you using FullPalette's DOpusRPFix? It's an option to FPPrefs v40.23, activated in a file ENVARC:FullPalette/DOpusRPFix with the contents "FULL". That ReleasePen() fix was once introduced as an addon for AmiKit. Do you have that patch installed? It doesn't work on my system anymore, but it did in the past. Try to remove it and see what happens with your screenmode switches.

Still couldn't find out what exactly goes wrong with releasepens. I already tried to lock the screen while releasepens is executed or not doing anything if it couldn't be locked. So there was no chance that the screen passes away, but it didn't help to fix the crashes. The only other argument is the icon and that icon is successfully remapped when I disable releasepens. No crash!

@AGS

In my opinion its hard work to code something that functions under all circumstances an Amiga system can encounter.

I've no ambitions to make everything possible on any system, but stability has a high priority and is more important than supporting all features everywhere.

[Michael]

!!! FULL will not work, the newer special hidden undocumented feature is required ... NORMAL

[PeterK]

No, even with NORMAL in DOpusRPFix 460 still crashes here on WB 3.1 + DOpus5. Did you try to disable it completely?

[Michael]

Crashes if disabled

If set to FULL, then all works fine too, but pens are released only on screenmode changes, and not when windows close (with 460)

[PeterK]

Update to icon.library 46.4.463:

The problem with releasepens under DOpus5 seems to be fixed now. DOpus5 tries to release the old pens in LayoutIconA() after doing the screenmode change. Either the screen or at least the screen depth changes. Now releasing pens is only allowed under DOpus5 if none of both has changed. Thus there are free pens again after closing windows.

[Michael]

Seems to be working perfectly now.
I did have a case once when switching modes 32->16>8 bit
and then opening/closing prefs drawer where I have a lot of icons.
For some reason the whole screen got colour corruption
backgrounds and birdy fills were wrong, icons were displayed correctly
Tried to repeat the case, but it is very solid at the moment.
Great job!

[daxb]

Originally Posted by PeterK

A pen is a color register in the Amiga graphics chipset. AGA has 256 color registers which can hold 24 bit RGB values, and OCS/ECS have only 16 color registers which can store 12 bit RGB and there is an EHB flag somewhere. Using the chipset means maximal 256 colors out of 16 million for AGA or 16 (32 with EHB) colors out of 4096 for OCS/ECS.

On a gfx card you can access the 15/16/24 bit RGB values (+alpha channel byte?) of every pixel directly with Read/WritePixelArray() if your software allows that.

Thanks for clarification. This is/was also my knowledge. I got confused by the limit of 256 with gfx card. Seems I misunderstood that what you wrote before.

[PeterK]

Some remarks to FullPalette's FPPrefs v40.23 and the option in ENVARC:FullPalette/DOpusRPFix:

-1) If FullPalette is not used at all you usually won't get any wrong colors after a screenmode change (since icon.library 46.4.463), but for 16 or 32 color screens FullPalette is always a good choice.

0.) If FPPrefs v40.23 is used, but DOpusRPFix not, you will sometimes get completely wrong colors after a real screenmode change, but not after a depth change. For example when you switch from HiRes to LowRes modes with the same depth then even the four system colors may get lost.

1.) If DOpusRPFix contains the keyword "NORMAL" then most of the colors will stay correct after switching to a different screen with the same depth, but some icons on the desktop may have a few corrupted colors. That can be fixed with a click onto the DOpus5 menu entry "Reset Icons".

The advantage of this mode is, as Michael said already, after closing windows the screen can still get free pens back and new apps may show slightly better colors.

2.) If DOPusRPFix contains the keyword "FULL" then all colors will appear correctly after any screenmode changes but the pens are never released again and new apps may not look optimal colored.

For OCS/ECS systems I would recommend to use FullPalette with DOpusRPFix FULL, because all colors are locked anyway.

FPPrefs v40.23 can be found in my Aminet package under ThirdParty/FullPalette.

[Michael]

DO5 icon info...
If we open icon info and then drop another icon to replace the image of the old icon and save our changes the old icon position (or unsnapshot status) will be lost and replaced by coordinates of the new icon if it was snapshoted. Limitation of DO5 or bug?