Caffeine OS does not use AfA OS and uses icon.library 51.4.568 (HB020) by PeterK

Caffeine OS has almost nothing of AROS 68k!

miker if you are interested in the attached link Peterk has created an Icon.library that does not use Datatypes!

https://eab.abime...ht=iconlib

Thanks for the information.

I did successfully extract OS4 icon data (ARGB chunks) using Icon Library to save as PNG images.

miker, my friend Peter said that discussions with you are welcome, his E-mail can be found under in the Aminet Readme and also in my IconLib.guide or IconLib.html under "Contact and Feedback".

http://aminet.net...onLib_46.4

Thanks again. I'm interested in talking to him about his Icon Library and some of the associated conversion programs such as ConvertPNGtoOS4. I'll contact him about it.

In the meantime I'll finalize the current version of Icon Splitter so I can start updating Icon Press to save Glow Icons using my new EncodeRLE. :-)

With some assistance from PeterK I have made some progress with Icon Splitter on Amiga 68k using his Icon Library to decode ARGB chunks from OS4 icons.

According to Peter his newest icon Library on Aminet (46.4.589) & every version above 586 have the icon control tags for Set/GetARGBImageDat1/2 just like AROS Icon Library. So I had to replace the icon Library in libs on Caffeine OS. It was as easy as renaming the old icon.library and copy the new one.

I had to add the icon tags from AROS icon.h file into the Amiga icon.h file in AmiDevCPP with some changes. I had to use (ICONA_Dummy+301) through (ICONA_Dummy+304). After that the Amiga version of Icon Split compiled correctly. At the point in Process_ARGB function where it would normally use datatypes to save the PNG image data I instead used WriteData function to save a bin file. I saved a ImageData1.bin on AROS & Amiga.

Using HxD hex editor the binary files of image data are identical. So Process_ARGB is working but saving with Datatypes isn't working. At this point I can revise the Datatypes save function to work with Amiga or I could use png.h (PNG library) to write my own LoadPng/SavePng functions to save the ARGB image data.

It's getting interesting. Thanks to PeterK for his patience and for explaining the programming interface for his Icon Library (written in ASM).

Ottimo lavoro, Peter è una persona speciale sono contento che ti abbia dato una mano, la collaborazione porta sempre a grandi risultati.

AMIGASYSTEM

Thanks for the kind words.

Peter has helped quite a bit so that I can get the image data from the ARGB chunks for OS4 icons using his newest icon Library.

At this point for Amiga 68k now the data has to be saved to an output image file such as PNG. But I can't get the Datatypes code to work and using PNG library directly also has problems.

So as a proof of concept to prove that the image data is correct I'm going to use my code from the save function for Targa Datatype to save 32bit ARGB data directly to Targa Files. I hope that works. No libraries will be used for that.

Saving directly to 32bit Targa is working on AROS x86 to save the ARGB chunk data.

Now I need to compile the new code to test on Amiga 68k (Caffeine OS) on PiStorm32 Lite using PeterK's Icon Library (46.4.589) to extract the ARGB image data from OS4 icons to save Targa.

Saving to Targa is a placeholder for using Datatypes to save as PNG on Amiga 68k. I will change the output file path method to save the actual icon filename with _1, _2 appended to the name so that the user knows which icon images it is.

Here is the Save Targa code that I'm using for AROS x86. We'll see if it works on Amiga 68k.

Targa and Windows BMP are very easy file formats to write to. Notice that for Targa (Truevision Graphics Adapter) the data can be RLE compressed using Targa RLE by pixel or it can be uncompressed.

The scanline data is reversed per scanline so that ARGB pixels becomes BGRA instead. Each scanline for Targa is then written from bottom to top of the file just like Windows BMP file format.

I chose Targa because it's an easy format and like PNG it can store 32bit image data. Most viewer programs that handle Targa only display it with an opaque background because most Targa files are 24bit. PaintDotNet and some other applications show it as transparent.