You may be wondering if Targa Datatype is fully functional what is the delay? Why not release it now? In my opinion it's not 100% complete. I have to re-write some parts & add a few new features. For ReadTarga & WriteTarga I want to support adding the Targa Footer "TRUEVISION-XFILE.. because the 8 bytes proceeding the Targa Footer is the Developers Area with optional data. We also have to support GREY8 images which are 8bit images with no ColorMap. And lastly, ReadTarga has to set CmpByteRun1 in the bmhd if the input image is RLE compressed. After all that it will be complete.

The screenshot shows MultiView using Targa Datatype opening the newly compressed 8bit RLE image. Pixelformer has some strange RLE sequences that are an RLE variant rather than PackBits. For example it writes a sequence similar to this: "04 AA BB CC DD.EE 00" where my WriteRLE function does this: "05 AA BB.CC DD EE". Pixelformer adds a zero as a padding byte at the end. It's not standard RLE but it can be read by Targa Datatype. It has no problem using ReadTarga to decode the non-standard RLE sequences. Pixelformer, however, is very picky!! If it's not the format it expects it says "Invalid Data" for the 8bit RLE. The other screenshot is my current version of 32bit AROS Native. I'll update my system files. Also, I plan to install AROS One x86 and x86-64 in a virtual machine for testing.

Actually, My WriteRLE function in Targa Datatype is working great ! At first I thought there was an error in the RLE conversion because the program I was using to make RLE compressed test images wouldn't open the newly encoded 8bit files. Pixelformer kept saying "Invalid Data". But Photoshop CS4, Gimp and PaintDotNet and even MultiView had no issues with the new 8bit RLE file. So it seems my new Targa Datatype can correctly encode RLE for 8,16,24,32 bit images!!

@deadwood Thanks for the links. I will do an update for my system files today or tomorrow. Now it's time to archive the datatype code that is now working correctly and enjoy the moment! 😁 Then back to work to finish up the new datatype. It's fully functional but I have to re-write parts & clean it up.

[quote name=miker1264 post=12195]@miker1264 Is there an update package for 32bit system files? How do I update my testing environment? [/quote] Here you can find the latest releases for 32-bit version: [url]https://axrt.org/downloads-aros[/url] If your testing environment was based of 20220318 release then there is an update package there to the latest release.

Success! Adjusting the WriteRLE line length using "width" instead of "width*2" solved it. Now it works great when saving Targa 16bit RLE. Now to fix 8bit RLE.

Actually WriteRGB16 uses "height - y - 1". Which seems correct now that I think of it. What a conundrum! The same code works perfectly to save 16bit images. But with RLE every other line is correct and the alternating lines are filled with junk pixels. Hmmm... I think I found the problem. It's not how I read the data from the Datatype obviously because that works fine to save 16bit without RLE. But instead when I send the 16bit scanline to WriteRLE instead of width I was sending bpr which is (width*2). The length of data is twice the length that it should be so it writes junk in between. Sometimes it's just small mistakes that cause such big problems!

@deadwood Thanks for the information. This weekend I'll refresh my sources for ABIv0 and rebuild the toolchain and rebuild AROS. With my old Toshiba P775 laptop with mechanical hard drive it took about 3 hours. Now I'm working with a new desktop with a fast SSD so it should take about 45 minutes. Is there an update package for 32bit system files? How do I update my testing environment? I found ABIv0: AROS 20220318-1-U3-any-i386_Update.zip but All others are x86-64 updates and iso's.

It rather suggests your test environment is missing the libraries that yor build system compiled the binary with.

Every other scanline is filled with junk. So I meticulously copied each good scanline to a new image to see what emerged. In the second screenshot the first ten lines at the top are copied from the banded image. The rest was spliced in from the original. They match up perfectly! Every other scanline in the banded image is good. The alternating scanlines are simply filled with junk pixel data. I suspect I know why. For the Targa Images the first scanline is at the bottom of the image because it has a Bottom-Up Orientation like Windows BMP. So in order to read the scanlines from the Datatype Object we should use "yoffset" instead of just "y" and the first value is "int yoffset = (height - 1)". After that each increment is simply "yoffset- -" to read up the image not down. But for some unknown reason WriteRGB16 currently uses "(y * height) - 1" every time we grab a scanline. That's wrong! So I'll makes some changes then recompile the datatype and try again. I'm using PictureDT Creation Tool because my 32bit and 64bit Build Systems have an issue. :-( @deadwood When I compile a program with my Build System then try to run it AROS has an error such as "stdlib is missing". Does that mean my sources and tool chain pre-date the clib change and updated? Or my test environment pre-dates the change?

Hmmm... I noticed that the banding effect for the Targa RLE 16bit image was very interesting, very regular. So I opened the image in PaintDotNet then zoomed in to see what it looks like! In the screenshot you can see that it looks like basket weaving. :-)

Last night I did some compiling and testing for Targa RLE compression. The RLE for 24bit and 32bit works. But not for 8bit and 16bit. In the screenshot you can see the banding. The same was true for Truecolor before I fixed the WriteRLE function. Although RLE compression isn't fully working I plan to move forward with releasing the Targa Datatype. Once it's in the repository it can modified.

Hi @amigasystem , Things drifted out of my initial roadmap, so, after a deep guru meditation 🙂, I will try a new approach, cause it was becoming a hacking aros centric initiative. First I will have a separate project for the classical chipset emulation (that was the initial idea anyway) https://github.com/JJDSNT/rigel And bellatrix will become a generic amiga machine emulation, with a plug-in system for expansions (i hope), that way, I will make a cleaner approach, with a proper cd rom support emulation that I can test against other roms instead of just try to make the iso boot. Have the 1.3 happy hand boot screen and aros boot screen was my primary goal, and we got it, (not KS3.1 yet), now it is time to clean up and tight things together before going forward. Let’s see what will emerge. Regards, Ps: ks1.3 does even boot workbench from an adf. (There is hope 😁)

There is a data type for MP3s on Aminet called ‘mpegadt’, but there are no source files! https://aminet.net/package/util/dtype/mpegadt.lha It would be nice to play MP3s with Multiview, but on AROS it’s no problem to play MP3s – there are several players available, including MPlayer

By the way, I was looking at my source code for Targa Datatype last night to see why Targa RLE wasn't working for 8bit and 16bit images. It seems odd that Truecolor 24/32bit works fine will Run Length Encoding. My WriteRLE function was designed to be very generic using bpp (bytes per pixel) such as 1,2,3,4 that deals with 8bit, 16bit, 24bit and 32bit respectively. If it works for one it should work for all bit depths. WriteRLE wasn't the problem. For WriteRGB16 I get the 24bit pixel data from the datatype. Then immediately after that is WriteRLE which is wrong. I was trying to use RLE encoding on the 24bit scan line. I have to convert the scan line to 16bit first then use WriteRLE. There were a few more issues that I fixed also. I haven't compiled it to test it yet but I'm confident it will probably work. I'll post some screenshots later today to show my progress so far.

AMIGASYSTEM, In the next few days I'd like to refresh my AROS Build Systems to get them ready to compile Datatypes for 32bit and 64bit. At that time I'll compile the current PixieView for both AROS 32bit and AROS 64bit. I plan to do some updates for PixieView after that such as adding Color Count, Display ColorMap, Color Histogram and some Graphics Effects. Most important, there will be a new display method to make it compatible with Amiga 68k/AROS. As far as MIDI Datatype I think I downloaded the sources. I'll take a look at it and try to build a datatype for AROS. Do we have an MP3 Datatype? If not it would be nice.

Great work as always, miker, is there a 64-bit version of PixieView available? Regarding Datatypes, Midi.Datatypes isn’t available on AROS systems; the source code is on Aminet, but I haven’t been able to compile it. https://aminet.net/package/util/dtype/MidiDT

Thanks Nigel. I started my AROS programming years ago it seems updating, fixing & writing Datatypes such as BMP, ILBM & Picture Datatype. You're right, Datatypes - picture, sound & text are the most widely used & most important system component.

Many thanks for this; Datatypes are one of the things which make Amigaoid systems special. I get so frustrated at work when trying to open a picture file or play a video and have to hunt around for a program that can handle that particular format. Cheers, Nigel.

With a 68000 CPU, AROS would take hours to load the operating system – assuming it can even support it. AROS 68k is based on Amiga OS 3.1, which requires a 68020 CPU. The best choice is an Amiga Expanded with at least a 68060 CPU; at the moment, the best experience is only available on WinUAE. See the configuration I have attached in the archive: AROS One 68k on WinUAE https://youtu.be/GI2WS4qum2k