Fix rtext default font alpha on Big Endian

[Fancy2209]

Alpha was broken for rtext's default font on Big Endian
Before

After

[raysan5]

@Fancy2209 It seems this patch addresses a specific use case for a specific hardware arquitecture... won't endianness affect other parts of raylib library? 🤔

[Fancy2209]

I tested some examples and they work, but I still have to test loading assets

Also it isn't just PowerPC/PowerPC64

I'll search for further issues with Big Endian
By the way, it isn't just PowerPC that's big endian, it's just the more common one

[Peter0x44]

Big endian is uncommon, but worth supporting. This will break all big endian systems, like powerpc linux, and sparc linux. Not that they are common, but it still matters to some users.

[Fancy2209]

Big endian is uncommon, but worth supporting. This will break all big endian systems, like powerpc linux, and sparc linux. Not that they are common, but it still matters to some users.

You mean this issue affects them too or that this PR breaks them?

[Peter0x44]

I mean the issue affects them. I think sparc and powerpc are the most relevant BE systems

[raysan5]

@Fancy2209 @Peter0x44 what is the cost of supporting big endian in raylib? It can require many changes and additional code complexity for a very specific set of platforms... if it implies only a couple of checks, it can be considered...

[Fancy2209]

I have to test all examples and find issues so it might take a bit
According to an article Peter0x44 code should always be endian independent anyways so it shouldn't be too hard to patch
I'll do a testing spree of all examples in a bit, fix the broken one and report back once I do so we can evaluate the complexity, though it shouldn't be very hard from my understanding

[raysan5]

@Fancy2209 ok, nice! 👍😄

[Peter0x44]

It implies no extra complexity, just a few minor edge cases need some extra care and attention
This case can actually be rewritten not to need the ifdef by writing both bytes of the short separately
Something like:

((unsigned char *)imFont.data)[(i + j)*sizeof(short)] = 0xFF
((unsigned char *)imFont.data)[(i + j)*sizeof(short) + 1] = 0x00;

[Fancy2209]

It implies no extra complexity, just a few minor edge cases need some extra care and attention This case can actually be rewritten not to need the ifdef by writing both bytes of the short separately Something like:

((unsigned char *)imFont.data)[(i + j)*sizeof(short)] = 0xFF
((unsigned char *)imFont.data)[(i + j)*sizeof(short) + 1] = 0x00;

Done, I still have to test loading Data from files though