Is BURNINGVIDEO bigendian aware?

[CuteAlien]

The fix for big endian is removing the #ifdef __BIG_ENDIAN__ parts? That's somewhat unexpected :-)
But thanks @Hendu! I'm just not sure right now if I should add that to 1.8 (always slight risk) or to trunk. Which version are you working with kas1e? Thought I suppose there probably was really no-one else using it with big endian maybe.

[devsh]

My 2 cents.

Endian conversion is only needed when you input or output data from a asystem of other endianness (hence why you need to check for it and swap bytes when reading files).
I guess that Burnings video does not care about endianness and Alpha is always in the logically higher 24bits for ARGB, now whether thats in the lower byte or higher after casting to uint8_t depends only on endianness.
Now if the driver only operates on 32bit values and uses bitmasks to extract components then no endian flags are needed, which is why I guess the fix of removing the BIG_ENDIAN ifdefs worked.

But now beware, OpenGL, GL ES, will not work with big-endian systems without byteswapping uploaded data such as vertex buffers.

[kas1e]

@CuteAlien
I do tests over 1.8.4 version, but probably will works with ogles one as well, as its all the same in that terms. That part from Software_helper.h as hendu says was only about colors, so its all fine then.

Through i dunno where to see now about that other error with the floor in the example "special fx", it seems like "almost" right, but still not fully.

On win32_x86:

http://kas1e.mikendezign.com/aos4/irrli ... 32_x86.jpg

On amigaos_ppc:

http://kas1e.mikendezign.com/aos4/irrli ... os_PPC.jpg
http://kas1e.mikendezign.com/aos4/irrli ... _PPC_2.jpg

Like somethig simple .. just where to look at...

[CuteAlien]

@devsh: The changed functions should only be used by burnings renderer. The endian define is still used in many other places which are not affected by this patch.

@kas1e: Links in your last post don't work, but I suppose the same as earlier? Not sure what's going on, but doesn't seem to be wrong colors, so that patch still looks fine. I'll apply the patch to Irrlicht trunk (and ogl-es when I merge). Won't add it to 1.8 for now in case it breaks some platform I don't know about (released branches shouldn't really change behavior except for bugfixing... so this one is slightly tricky as it changes behavior but probably only fixes bugs...).