icon.library 46.4 test versions

[Retrofan]

I've tried with Visual prefs disabled and also all of the WBStartup disabled including MagicMenu. FPPrefs using yours and also the new FullPalete.prefs, but it keeps the same. That's on workbench with Cybergraphix disabled and also Birdie. I'm using 16 colors.
Have you tried Ken's icons?

[PeterK]

What? You're using 16 colors ???

If you want to use HAM8, then forget about Rebels palette and any icons or pictures made for it.

No my library supports HAM8 with 64 basic colors, but not HAM6 with 16 basic colors.

Look on my screenshot on the previous page for Ken's icons.

[AMIGASYSTEM]

Ok Peter I will not give you any more signal, thanks anyway.

[Retrofan]

Ups, no, sorry I selected with MuiScreenmode Pal High Res Laced 724x566 with 64 colors. I must have something wrong.

[PeterK]

Did you also switch on the HAM mode? But it looks like HAM is enable and only a few colors are overwritten by something else.

@AMIGASYSTEM
Sorry for my criticism concerning AfA. I will try to find a workaround if possible, but I hate to make all these fixes for bugs in other systems. I can find enough bugs in my own code already.

[AMIGASYSTEM]

I do not care so much about the changes, I thought the problem could interest you, the AROS icons of the "Nightly build" "single face" (like those of the PC)

The problem happens when I save icons on AFA-OS, this happens only with this type of icons and it happens even if I use your library with AFA-OS, which I currently use and works great on AFA-OS.

[Retrofan]

I've got it

I've had to load the FullPalette.prefs and save them. Where does it save them then?. I load the FPPrefs in the s-s from Sys:Utilities/Expansion/FullPalette and there is where I had your new files. It seems that I'll have to save FullPalette.pres in Env-Archive, I guess.

EDIT: Please I need an 800x600 wallpaper in HAM8 to try.

Ahem... Peter this seems to be nice

[PeterK]

Originally Posted by PeterK

You will also need to install my FullPalette.prefs file in ENVARC:Sys ...

What is the problem with the wallpaper? WBPattern can still use the 64 base colors of the palette like any other image viewer, too. The disadvantage is that all these 64 colors are locked and there are no free pens left which WBPattern could allocate for optimizing the wallpaper colors.

Anyway, I'm glad that you could finally get HAM8 to work on your system. Good night ...

[Retrofan]

Originally Posted by PeterK

What is the problem with the wallpaper? WBPattern can still use the 64 base colors of the palette like any other image viewer, too. The disadvantage is that all these 64 colors are locked and there are no free pens left which WBPattern could allocate for optimizing the wallpaper colors.

Anyway, I'm glad that you could finally get HAM8 to work on your system. Good night ...

The thing is that using 64 colors in HAM mode your icons look like with RTG (yep, they couldn't be any better ), but the wallpaper has no improvement; it looks just like using 16 colors, that's why I was thinking in another kind of images made for HAM.

Well... I haven't read any readme and maybe there is an option in MUIScreenmode that I should check?

The best wallpaper I can get is using "V" from @meynaf (thanks a lot and also for fixing it today) from here: http://eab.abime.net/showpost.php?p=1076655&postcount=3 and saving the image using QuickGrab http://aminet.net/package/gfx/misc/QuickGrab1_1

https://s33.postimg.cc/qmd6uw5rh/HAM.png?dl=1



Maybe you've got an idea about how to obtain the best wallpaper for it?
Edit: I've found some info:
http://eab.abime.net/showpost.php?p=453402&postcount=10

As you can see there is a problem with the icons in WBDock from Thomas Rapp.

Edit: It works with CyberbugFixAga , Birdie, VisualPrefs and MagicMenu. All of them have been enabled after that screenshot. AmiDock shows the icons right.

[PeterK]

I don't know if there exists any wallpaper tool which can display in HAM8 too and is able to use the base colors of my palette? That would give perfect results.

It seems that WBDock by Thomas Rapp is not public yet, it's not on his homepage, nor on Aminet. So what is its status? Where can I get documentation about possible options for pen settings? Where is a download link except that it might be included in the giga distro of AKReal? I don't want to blame Thomas for not supporting a palette where all pens are already allocated and locked, but maybe WBDock has an option to use shared pens too? I don't know WBDock yet, since I've none of the available docks installed.

[Retrofan]

About wallpapers, as Thomas said years ago,

Originally Posted by thomas

It does not work this way. Workbench always dithers the background picture into the screen's pen system and it takes care that a reasonable number of pens stays free for applications. So you cannot use a picture which has as many colors as the screen. You have to use a picture with less colors. Best is if the picture has half the number of colors as the screen has pens. So if your Workbench screen has 64 colors, your background picture should not have more than 32 colors.

It does not matter which palette the picture has. Only the first and the last four pens are reserved by Workbench. The remaining colors change on every reboot, especially if you use remapped icons (NewIcons, GlowIcons). It's just wasted time to grab the Workbench screen first.

I think that I better use one with few colors, like this:

Originally Posted by PeterK

I don't know if there exists any wallpaper tool which can display in HAM8 too and is able to use the base colors of my palette? That would give perfect results.

Yep, that would be amazing. I haven't found anything, but if it could somehow use some code of the viewer I've commented in my previous post by meynaf, it works great and fast.

[PeterK]

So if your Workbench screen has 64 colors, your background picture should not have more than 32 colors.

It does not matter which palette the picture has. Only the first and the last four pens are reserved by Workbench. The remaining colors change on every reboot, .... It's just wasted time to grab the Workbench screen first.

That's all true for a normal Workbench, but not for my HAM8 Workbench.

Again, all the 64 pens have fixed colors and are locked. These colors are always there , even after a reboot, and should never be changed by any tool. So you can rely on all 64 base colors at any time and it makes sense to optimize your HAM8 wallpapers for all these 64 colors of the WB screen palette. Of course, a wallpaper with less colors will work too.

The 64 base colors should exactly look like on this FullPalette Prefs screenshot. The upper 192 colors are not available for images. They are only displayed here, because HAM8 appears as an 8-bit screen to FullPalette.
There is a new palette in 499u.

[thomas]

I suppose the issue is only with the "Funny" style of WBDock, right?

All other styles use the icon's images as they are. Only the funny style scales them to match a certain size. IIRC it uses graphics.library/BitMapScale for that. This function works directly on the bitmap's pixels. Of course this does not work with HAM. In HAM each pixel's color is dependent on its left neighbour. If I cut the neighbour away the color will change.

I would have to convert the bitmap to 24 bits, do proper true-color scaling and then convert it back to HAM. The latter will probably not be too easy for an irregularly shaped image.

What's the easiest way to get a test environment?

[PeterK]

Sorry, but I have not a clue about your WBDock proggy yet, since I don't use any docks and also found no public download link for WBDock.

But your info may help Retrofan to choose other options for WBDock to let it work on HAM screens too.

To get my icon.library HM020 working in HAM8 mode, you will need MUIScrModePrefs from Aminet and you have to install my supplied FullPalette.prefs file from 46.4.499 in ENVARC:Sys and call FPPrefs in your startup-sequence. There should be no other tools in the system making any changes to the 64 base colors, like color daemons or VisualPrefs setting pens. It works for me on all WB 3.x versions with PAL, SuperPlus and HighGfx screens in HAM8 mode (NTSC and other native Amiga monitor drivers not tested yet).

Update:

Only the funny style scales them to match a certain size. IIRC it uses graphics.library/BitMapScale for that. This function works directly on the bitmap's pixels. Of course this does not work with HAM.

@Thomas
After thinking a bit about your explanation I realized that it would mean your BitMapScale() is executed after my HAM conversion was done. But all my HAM8 handling occures in my gfxpatch for the Blt(Mask)BitMapRastPort() functions. So your WBDock must have installed another patch even earlier than my library, which is usually called by IPrefs for the first time. Could that be possible?

In case that your WBDock would use BitMapScale() before my gfxpatch is executed nothing should go wrong, because my HAM8 code converts the normal bitmaps with the colormapped images only if their size is still the same as the width and hight in my hidden (appended) PalMap structure. Otherwise a scaled normal image mapped to the 64 colors would just bypass my patch without a HAM8 conversion.

@Retrofan
I still don't know WBDock, but if it is called in the startup-sequnce before IPrefs then you could try to move it down closer to LoadWB, in order to execute it after icon.library has been loaded.

[thomas]

I don't install any patch, why should I?

I draw the icon into a bitmap and then scale the bitmap.

[PeterK]

Hmm, I have never used BitMapScale() yet. Do you have to call it before or after Blt(Mask)BitMapRastPort()?

I just wonder why your small icons seem to have some HAM artefacts on Retrofan's screenshot. That would mean that the scaling was done after my patch for Blt(Mask)BitMapRastport() was executed. How can that happen?

Where can I get WBDock for some tests?

[thomas]

There is no relation between BitMapScale and Blt#?.

You have bitmap1 which is for example 100 x 100 pixels and bitmap2 which is for example 50 x 50 pixels. When you call BitMapScale with the respective arguments it will (in this example) copy every second pixel from every second row of bitmap1 into bitmap2.

In my case I use DrawImage to draw the icon into bitmap1 and later use BltMaskBitMapRastPort to draw bitmap2 into the window. I guess your HAM conversion happens during DrawImage.

[thomas]

Here is the current WIP version of WBDock2:

http://thomas-rapp.homepage.t-online...ga/wbdock2.lha

[PeterK]

Yes ok, DrawImage() is an intuition function, which I also don't know yet

It could be possible from what I can read in the autodocs that DrawImage() indeed calls Blt(Mask)BitMapRastPort() itself before you use BitMapScale() and finally then call Blt(Mask)BitMapRastPort() again. That would make sense now, because then the HAM conversion would be done in the 1. blit call before the scaling is done and in the 2. blit call the already damaged HAM image would just bypass my patch because it's a new bitmap anyway without the magic token which my gfxpatch tries to find appended to the image data.

Thanks for your WBDock, I will try that soon.

[Retrofan]

Thanks Thomas, I see a much better option to edit the configuration in this beta.

Peter what I mean is that if I take an image and I remap it and apply whatever dithering then the image will look dithered and I don't want that, to match with the nice icons. So yes, as you say, it would be nice to find a way to get a HAM image that could use your palette.

Could you get a palette (pal) to try with Ultimate Paint from your palette, just to try?. I've tried with "Retro Image Tool" using the image of the palette as palette for it but it shows too much dithering. What a pity that it doesn't have an option to convert to HAM.