EDanaToo wrote:
The Amiga OS 3.1 version looks exactly as it should, so I'm assuming this has something to do with Cybergraphics, or perhaps byte alignment on RGB or the color palette being used.

To draw RGB pixels on truecolors screens you can use cybergraphics.library/WritePixelArray(rectfmt = RECTFMT_RGB or RECTFMT_ARGB or RECTFMT_RGBA).

RGB = R8 G8 B8 R8 G8 B8 ... ARGB = A8 R8 G8 B8 A8 R8 G8 B8 ... ...

in memory, independent of endianess of computer.

The pixel buffer will be converted to the destination bitmap pixel format automatically but this conversion may be slow as we have only one general slow conversion routine.

Better would be to use RECTFMT_RAW which means same pixel format as destination bitmap. Then you would have to do the conversion yourself before calling WritePixelArray(RECTFMT_RAW).

Pixel and rectformats in AROS cybergraphics always refer to the layout in memory. So RECTFMT_ARGB means 0xAA 0xRR 0xGG 0xBB. And this is so no matter if running on big endian or little endian machine. This is important to know for when running on little endian (x86) machine, because then if you have an ULONG pixel array/buffer where you write ARGB pixels into it using pixel (ULONG) accesses then in memory it will look like 0xBB 0xGG 0xRR 0xAA and you would need to use RECTFMT_BGRA.

This is an endianess thing. On AROS big endian it's exactly the same as in AOS/MOS. Because pixel access/component access/memory layout on big endian machine does not make a difference. If you write a 0xAARRGGBB ULONG to memory it will be 0xAA 0xRR 0xGG 0xBB in memory, too. Same thing. No problem.

On little endian machine it was something of a design decision whether the RECTFMTs/PIXFMTs should reflect pixel access based meaning (unit == pixel) or memory layout based meaning (unit == byte or component). Because RECTFMT_ARGB does not mean that one by force always uses ULONG pixel buffers and only ULONG pixel accesses. One may also use byte/component access. Or read/write such pixel buffers to/from disk.