Fix: RGB values set by macro MFP_RGB on Android platforms where CPU is either running in little (seems to be the default) or big endian.

[enjector]

Noticed all my colours were wrong on Android and other platforms worked fine.

This is a fix for RGB values set by macro MFP_RGB on Android platforms where CPU is either running in little (seems to be the default) or big endian.

"Since code runs on the little endian CPU, red color in 'rgb' would be masked as 0x000000ff, and blue color would be masked as 0x00ff0000, while if the code runs on a big endian CPU, the red color in 'rgb' would be masked as 0xff000000, and blue color would be masked as 0x0000ff00."

This is easily demonstrated by updated test: src/main/cpp/noise.c:
...
// Comment out to test appropriate colour channel
//g_buffer[i] = MFB_RGB(noise, 0, 0); // Test red channel
//g_buffer[i] = MFB_RGB(0, noise, 0); // Test green channel
//g_buffer[i] = MFB_RGB(0, 0, noise); // Test blue channel
g_buffer[i] = MFB_RGB(noise, noise, noise);
...

The uint32 value RGB values is set as blue, green then red. Tested on real devices with arm64-v8a and armeabi-v7a and on x86 emulator).

MFB_RGB works fine as-is on X11, Windows, MacOS and iOS platforms.

[Darky-Lucera]

It seems that almost all Android phones and emulators work in little-endian (ARM is able to work on both endians).

We are using a buffer with format 0xAARRGGBB (strictly speaking we are not using alpha), and this corresponds to the old screen formats, to the OpenGL format GL_BGRA and to the Metal format bgra8Unorm.

But in Android, the native screen format is reversed 0xAABBGGRR (GL_RGBA8, rgba8Unorm).

I cannot access any Big Endian device but as you are reversing the bytes unless HOST_WORDS_BIGENDIAN is defined, I guess it will fix the issue for now.

I was planning to add support for OpenGL on Android. I'll have to keep this in mind later.

Thanks a lot for your contribution.