:bump:

Chris, why don't you write a small program which lets us reproduce the problem? Then tell us how the result on AROS differs from the other platforms. We can only create a source compatible OS if we get feedback about differences.

@Georg
1 bit to 24 bit blit:
24 bit to 1 bit blit:
All I can tell you is that I tested (essentially) the same code on AmigaOS4, and it worked! I'll try to remember to look into this when I have time, to see what OS4 was actually doing.


I see that you are also answering an unrelated bug report I made:
http://sourceforge.net/tracker/?func=detail&aid=3513395&group_id=43586&atid=439463
Quote:
Hmmm, endian issues hadn't occured to me, and it probably does explain what I saw (I'll have to check if R & B were really swapped).

It is a shame that AROS can't have the responsibility to do the byte-swapping, as the whole point of Read/WritePixelArray() is that you don't have to worry about how the pixel data is stored in memory. It *could* have done so, were it not for RECTFMT_RGB (which does not cleanly map to any char/int/long array).

1 bit to 24 bit blit:

Since bitmaps with <= 8 bits don't contain color information, the blit needs to have some LUT/palette info to map the pixels in the 1 bit bitmap to truecolor pixels in the 24 bit bitmap. If a bitmap is a friend bitmap of a screen bitmap, then that's where a LUT/palette can be obtained from. If not, it can't do the mapping. Theoretically it could just move the 1 bit src pixel over to dest unmodified (or convert it to full black/full white), but does AOS3/AOS4/MOS really do that?

24 bit to 1 bit blit:

Does AOS3/AOS4/MOS support that? Is even trickier: dither or not? If no LUT/palette for 1 bit bitplane, what is pixel value 0: black or white?

RECTFMT_ARGB <-> RECTFMT_RGBA:

Are you sure you don't mean RECTFMT_ARGB -> RECTFMT_BGRA? The thing with RECTFMT_#? on little endian x86 AROS is, that they are #defined based on how the color components look in memory. RECTFMT_ARGB in memory is always 0xAA, 0xRR, 0xGG, 0xBB, 0xAA, 0xRR, 0xGG, 0xBB, ... both on big endian and little endian machine. If you use LONG writes/reads to memory on little endian machine this means either:

- specify the pixels in 0xBBGGRRAA format and use RECTFMT_ARGB

- specify the pixels in 0xAARRGGBB format and use RECTFMT_BGRA32

And just in case anyone misses the point of this post: I know this is not the most efficient set of work-arounds, but it seems the simplest general-purpose (and half-decent performing) one... and my point was really that these two bugs conspire to make scaling <=8-bit bitmaps much harder than it needs to be on AROS.

I've just reported a couple of very-long-standing AROS bugs:
http://sourceforge.net/tracker/index.php?func=detail&aid=3513312&group_id=43586&atid=439463
http://sourceforge.net/tracker/index.php?func=detail&aid=3513315&group_id=43586&atid=439463
(My bug comments say 88 times, but I just realised it is actually 45 times.)

When scaling a 1-bit mask, I have to work-around both of these bugs. The end result is that temporarily I have to use 45 times the amount of memory that I should need!!!

BitMapScale() gives the wrong result for any depth <=8-bits, so I have to copy my 1-bit mask into a 24-bit bitmap. And the scaling result has to go into another 24-bit bitmap. So that is 48-bits/2-bits (per pixel) = 24 times extra already.

But BltBitMap() does not work at all when blitting between 1-bit & 24-bit bitmaps (in either direction), so to achieve something vaguely fast I have resorted to using ReadPixelArray8()+WritePixelArray() (and vice versa). That means allocating a char array (8-bits) plus a long array (32-bits). Meaning 40-bits/2-bits (per pixel) = 20 times extra.

So instead of using 2-bits per pixel, I am temporarily using 2+48+40 bits = 90-bits! i.e. 45 times what I should need!