icon.library 46.4 test versions

[Michael]

@PeterK:
New problem with DO.
Now if you select Icon info (Icon edit window), and then click on the icon to see it's other image, the first time you click it, the image is shifted to far bottom right.
Clicking it again and again, it is in the correct place! So only the first click is wrong. (looks like you are not putting the coordinates back to 0,0 when skipping remapping)

[Thorham]

To PeterK:

How easy/hard would it be to add HAM rendering to your library if you had a good, easy to use HAM render routine? Workbench screens can run in HAM modes, so that's no problem (there's a screen mode prefs replacement on Aminet that allows this).

[PeterK]

@Michael
The shifted image in DOpus5 Icon Info is not a NEW problem for me. To fix it I would have to exclude the task "dopus_icon_info" from the delayed color mapping. Not sure if that is worth the trouble (more code, slow down of other things). The DO desktop and the listers don't have this problem. And SwazInfo on WB 3.1 works also correct.

@Thorham
This would need a complete new color mapping and a replacement for chunkytoplanar. No sorry, nothing for me.

[daxb]

@Michael:
You may know almost every Amiga system is different (e.g. screen solution). IMHO the best test enviroment (except clean boot, no background tasks running, ...) is to have a window size near screen size with as many as possible visible icons. You know that open a window without an icon takes already time but we want the time for drawing icons. So a small window with only a few icons isn`t a good choice.

[Michael]

@PeterK:

I have found out one more interesting fact about those shifts.
Apparently they happen not always and only for 3.5 icons!
eg.
if we get info on an unselected icons -> click -> shifted image
if we get info on a selected icons -> click -> no shifted image
if we repeat above again -> shifted image
if we get info on unselected icon again ->, no shifted image

very odd, but definitely something is not set to correct position in one of the cases, classic icons are not effected.

[Thorham]

Originally Posted by PeterK

This would need a complete new color mapping and a replacement for chunkytoplanar. No sorry, nothing for me.

Okay, perhaps I'll take a look at it. Apart from those two things, how hard is it to add? Existing c2p can be used (HAM doesn't need a special c2p, just normal six or eight bit c2p), and color mapping is handled by the HAM render routine using a table (easy to generate).

[Retrofan]

Originally Posted by PeterK

@Retrofan

Should be posiible with ProcessIcon from Stephan Rupprecht to batch delete the planar images.

Thanks PeterK. Unfortunately I'm only making it in a batch process to get both dual png's images with ImageConverter with an script and also when converting them to 16 colors (real batch process though subfolders with Ultimate Paint in the Pc with a palette based on your FPPrefs). But to make each icon I'm using EditIcon... -as that's the best way I believe-, and later of course CopyIcon as the most of the 8114 icons are repeated -I've got opened 8-10 CopyIcons images to copy from at the same time-, so it doesn't matter to make another step and delete the old image.

Well, I've got almost all of them remapped and I'm wishing to finish and share -maybe tomorrow- to try an speed test to see if all of this was worthwhile .

[Michael]

@Retrofan:
Make sure you don't brake the icon dimensions. They should all be the same size. I believe 46x46 is the current default for Gi.

[Retrofan]

Originally Posted by Michael

@Retrofan:
Make sure you don't brake the icon dimensions. They should all be the same size. I believe 46x46 is the current default for Gi.

Yes, I keep the same size. But I also minimize the sketchboard (space around), so you can have more icons the same size in the same place.

[James]

Originally Posted by Retrofan

Yes, I keep the same size. But I also minimize the sketchboard (space around), so you can have more icons the same size in the same place.

The space around the icon is included in the size, and removing it can mess up the alignment. Example:
Look at the default drawer compared to an image drawer. The image drawer has an extra bit (image) sticking out on the left, so the default drawer needs to allow for this extra space on the left, so that the sides of both drawers are still in line when they are arranged in columns.

[ancalimon]

I remember using a program to remove the "invisible border" from some of the icons 10 years ago so that they don't cover other icons. Does anyone remember the name?

[PeterK]

Originally Posted by Thorham

Apart from those two things, how hard is it to add? Existing c2p can be used (HAM doesn't need a special c2p, just normal six or eight bit c2p), and color mapping is handled by the HAM render routine using a table (easy to generate).

It's not that easy as you may believe, Thorham.
You can not simply add some alternative routines to the icon.library, but you will also have to create a complete new icon data structure.

The current OS 3.5 format has a chunky pixel information pointing to up to 256 RGB colors (24 bit) and a 256 byte table mapping these colors to the screens pens. But this format won't fit to represent the HAM6 or HAM8 data. So, you need to write a complete new icon structure to hold the HAM info in addition to the existing DiskObject structure. That means that nearly all parts of the icon.library have to be rewritten from scratch. And every existing tool for icons will destroy your HAM data again.

I would suggest to load the fixed 16 color palette from my Aminet release with FPPrefs instead. Retrofan is just working on a special iconset that is optimized for such a palette.

[Retrofan]

James PM sent to discuss details and not going off topic here

Edit: But I see you are right. I won't minimize them (so I will start again).

[Thorham]

Originally Posted by PeterK

The current OS 3.5 format has a chunky pixel information pointing to up to 256 RGB colors (24 bit) and a 256 byte table mapping these colors to the screens pens. But this format won't fit to represent the HAM6 or HAM8 data.

The way this should work is pretty simple. The HAM renderer fetches a pixel (just like your remapping routine does), converts it to HAM, and sends the six or eight bit data to the c2p. As long as the HAM renderer can get hold of the 24 bit color data for the pixels in the icon, it can generate the right output data. The process is similar to your remap routine, except you convert to HAM and not a normal indexed mode.

Originally Posted by PeterK

I would suggest to load the fixed 16 color palette from my Aminet release with FPPrefs instead. Retrofan is just working on a special iconset that is optimized for such a palette.

Interesting, I'll check it out.

[PeterK]

Originally Posted by Thorham

The way this should work is pretty simple. The HAM renderer fetches a pixel (just like your remapping routine does), converts it to HAM, and sends the six or eight bit data to the c2p. As long as the HAM renderer can get hold of the 24 bit color data for the pixels in the icon, it can generate the right output data. The process is similar to your remap routine, except you convert to HAM and not a normal indexed mode.

Ok, I understand what you want to do, but this would mean that you will only get up to 256 colors out of 4096 or out of 262144 and not 4096 or 262144 out of 16777216 colors. And nevertheless, it won't be pretty simple, and I still don't want to do it. But since you already know how to recompile my icon.library and you obviously also have a much better knowledge about HAM rendering and C2P conversion than me, I would recommend to try it on your own. I noticed that you always know how to make things better, so why not starting your own project and learn to fight with the details?

[Thorham]

Originally Posted by PeterK

but this would mean that you will only get up to 256 colors out of 4096 or out of 262144 and not 4096 or 262144 out of 16777216 colors.

Yes, that's true. You'd still get 256 colors per icon, though.

Originally Posted by PeterK

and I still don't want to do it.

Yeah, I can understand that

Originally Posted by PeterK

I would recommend to try it on your own.

Took a look at your source code, and I wouldn't know where to put the new code. What I need is a pointer to the icon's palette table, the icon's indexed pixel data and a way to skip the remapping process, but I can't find them

Originally Posted by PeterK

I noticed that you always know how to make things better, so why not starting your own project and learn to fight with the details?

Yeah, good one I guess the theory is always the fun part

[PeterK]

@Thorham
The new code must be able to replace my subroutine "imagecolormapping" at line 2782. But the old code is still required for programs that need the color mapped output as it is now. This subroutine is called with the following contents in the registers:
D0 = the planar image structure GadgetRender or SelectRender
D7 = the requested color precision -1, 0, 16 or 32 for the pen allocation
A0 = the icons screen pointer
A1 = the PalMap structure, info is appended at the end of my source code
A3 = the icons extended OS 3.5 DiskObject structure, see also at the end
A5 = the icon.library base pointer

The pointer to the RGB palette table can be found at offset $108 in the PalMap structure. And the pointer to the pixel data index bytes is at offset 4. The mapping table for the colors to the screens pens is from offset 8 to $107.

PalMap:

$112+   274+ sizeof(PalMap)
===============================
 $00      0     2   width
 $02      2     2   height
 $04      4     4   * image bytes (->offset $114)
 $08      8   256   colormap CLUT (->screen pens)
$108    264     4   * colormap RGB bytes (below)
$10c    268     1   flags, bit 0 = transparency
$10d    269     1   transparent color reg number
$10e    270     2   number of image colors
$110    272     2   number of image colors mapped
-------------------------------------------------
$112            2   alignment for faster copying
$114    276   xxx   image bytes (->colormap CLUT)
$???    ???   xxx   colormap RGB bytes (24 bit)

Finally, it's your task to create the new HAM planar ImageData for the image structure (D0) at offset $A, replacing an existing pointer, and adjusting the width (PalMap), height(PalMap), depth (of the HAM screen), PlanePick and PlaneOnOff entries.

I've really no idea how PlanePick and PlaneOnOff are handled in HAM-modes ?? Have fun !

Image:

 $14     20  sizeof(Image)
=========================
 $00      0     2  LeftEdge
 $02      2     2  TopEdge
 $04      4     2  Width
 $06      6     2  Height
 $08      8     2  Depth
 $0a     10     4  * ImageData
 $0e     14     1  PlanePick
 $0f     15     1  PlaneOnOff
 $10     16     4  * NextImage

[Thorham]

To PeterK:

Thanks

Doesn't seem too hard, but I have a feeling it might be harder than I thought it would be. I'll see what I can do with the info you provided. Would be a pity if I couldn't get it to work, because nice HAM rendering isn't very complicated, and not very slow, either (for example, error diffusion based dithers are slower).

[Michael]

Is not it simpler to use the old planar format for HAM icons ?
You only need to lock the first primary colours, the rest are just coper offsets.
The old lib worked fine like that. No idea if the current lib can do the same, theoreticaly, if it is not remapping anything, planar data should be transparent to the lib and only effects the screenmode. Those icons will work properly only on HAM screens only so. I had an example set uploaded to aminet a decade ago ;-)

[PeterK]

I'm not sure if the Workbench is able to blit HAM images onto a HAM screen at all. I would recommend to check that first and to see how to handle PlanePick and PlaneOnOff if it's possible.

Update: I've just checked out with MUIScreenmode what the limitations for a PAL HiRes Interlaced screen with the HAM option enabled are:

This "HAM screenmode" supports only 64 colors and not 4096! Even in LowRes it's not more than 64 colors. And a HAM8 option is not available. Project done ...