Is BURNINGVIDEO bigendian aware?

[kas1e]

@CuteAlien
I have __BIG_ENDIAN__ enabled in GCC already, i.e. simple test case:

Code: Select all

 
#include <stdio.h>
 
int main()
{
#ifdef __BIG_ENDIAN__
printf ("we on BIG endian\n");
#else
printf ("we on LITTLE endian\n");
#endif
return 0;
}
 

Give me "we on BIG endian" , what mean __BIG_ENDIAN__ ifdef taken in account.

But i also search on whole source, files with words "BURNING", and all files i found, have not ifdefs about __BIG_ENDIAN__ , what make me think author just wasn't worry. But seeing how it all already work, and only colors swapped, i feel it is something simple should be , somewhere colors passed in wrong order..

[CuteAlien]

Strange that the terrainscenenode seems to have correct colors.

[kas1e]

That skybox + earth thing ? Yeah, i compare with win32 version and sky and earth seems same colors as should. Same as irrlicht logo. What also intersting is when i do in that 09 mesh viewer "GUI Transparet control" full transparent, it didn't make trasparent but change color from green to yellow. Its cleary byte-swapping somewhere should be done

[kas1e]

@All
I compile 1.5.2 version of Irrlicht (that one, old one, from 2009 year). And there burning's video looks a bit different. I.e. the same wrong colors, but quality is much better:

http://kas1e.mikendezign.com/aos4/irrli ... _1_5_2.jpg
http://kas1e.mikendezign.com/aos4/irrli ... _1_5_2.jpg
http://kas1e.mikendezign.com/aos4/irrli ... _1_5_2.jpg
http://kas1e.mikendezign.com/aos4/irrli ... _1_5_2.jpg

I also got an answer from Thomas (author of Burnings Video renderer), he sadly have no time to worry about, but he give me a nice tips : we should search for any bit shifting. So, its kind of isolate problem, and i just do search for "burnings" in whole sources, and in files i find, i do search on "<<" and on ">>" (so for bit shifting), and basically there is only source/IrrLicht/S4DVerthe.h file left, which have:

Code: Select all

 
// A8R8G8B8
struct sVec4;
struct sCompressedVec4
{
    u32 argb;
 
    void setA8R8G8B8 ( u32 value )
    {
        argb = value;
    }
 
    void setColorf ( const video::SColorf & color )
    {
        argb = core::floor32 ( color.a * 255.f ) << 24 |
                core::floor32 ( color.r * 255.f ) << 16 |
                core::floor32 ( color.g * 255.f ) << 8  |
                core::floor32 ( color.b * 255.f );
    }
 
    void setVec4 ( const sVec4 & v );
 
    // f = a * t + b * ( 1 - t )
    void interpolate(const sCompressedVec4& a, const sCompressedVec4& b, const f32 t)
    {
        argb = PixelBlend32 ( b.argb, a.argb, core::floor32 ( t * 256.f ) );
    }
 
 
};
 

Code: Select all

 
inline void sCompressedVec4::setVec4 ( const sVec4 & v )
{
    argb = core::floor32 ( v.x * 255.f ) << 24 |
            core::floor32 ( v.y * 255.f ) << 16 |
            core::floor32 ( v.z * 255.f ) << 8  |
            core::floor32 ( v.w * 255.f );
}
 

Code: Select all

 
    void setA8R8G8B8 ( u32 argb )
    {
        x = ( ( argb & 0xFF000000 ) >> 24 ) * ( 1.f / 255.f );
        y = ( ( argb & 0x00FF0000 ) >> 16 ) * ( 1.f / 255.f );
        z = ( ( argb & 0x0000FF00 ) >>  8 ) * ( 1.f / 255.f );
        w = ( ( argb & 0x000000FF )       ) * ( 1.f / 255.f );
    }
 
    void setR8G8B8 ( u32 argb )
    {
        r = ( ( argb & 0x00FF0000 ) >> 16 ) * ( 1.f / 255.f );
        g = ( ( argb & 0x0000FF00 ) >>  8 ) * ( 1.f / 255.f );
        b = ( ( argb & 0x000000FF )       ) * ( 1.f / 255.f );
    }
 

So probably it can be it. As we have problems with colors only ..

[CuteAlien]

Maybe set a breakpoint and check if any of those are called. Or simply flip the order for testing and see if it improves. If so we can add an ifdef there. I don't know what changed in Burnings renderer since 1.5 as I've not touched that one.

[kas1e]

@CuteAlien
Checked, and so far only setA8R8G8B8() is called from above mentioned functions when i run 09-meshviewer example. I just trying that way for fast check (swapped x,y,z,w other way around, without swapping shifting itself):

Code: Select all

 
    void setA8R8G8B8 ( u32 argb )
    {
        printf("we call setA8R8G8B8\n");
#ifdef __BIG_ENDIAN__
        w = ( ( argb & 0xFF000000 ) >> 24 ) * ( 1.f / 255.f );
        z = ( ( argb & 0x00FF0000 ) >> 16 ) * ( 1.f / 255.f );
        y = ( ( argb & 0x0000FF00 ) >>  8 ) * ( 1.f / 255.f );
        x = ( ( argb & 0x000000FF )       ) * ( 1.f / 255.f );
#else       
        x = ( ( argb & 0xFF000000 ) >> 24 ) * ( 1.f / 255.f );
        y = ( ( argb & 0x00FF0000 ) >> 16 ) * ( 1.f / 255.f );
        z = ( ( argb & 0x0000FF00 ) >>  8 ) * ( 1.f / 255.f );
        w = ( ( argb & 0x000000FF )       ) * ( 1.f / 255.f );
#endif      
    }
 

That make whole gui be transparent. If i radomly make other shifting, the colors of dwarf changed. Probabaly that can be it , if only do shifting right.

[CuteAlien]

Just to be sure - the solution you posted makes the colors look correct for you now?

[kas1e]

@CuteAlien
No no, it the same problem

Just the way i do it in above example whole GUI now transparent (while should't of course). I do it just to see if that part of code related to color problems at all. But there need to understand all that code and make "normal" big-endian ifdefs, which will make things works. And i do not undestand at moment what color space is used there, as for RGB with alpha there can be four different variants: ARGB, RGBA, BGRA and ABGR. I will try in meanwhile to understand how to deal with, but help of expirience coders need it of course

[CuteAlien]

Ah OK. I thought it worked because the UI in that example is partly transparent.

[kas1e]

At moment only isolate color problems with GUI : CSoftwareDriver2.cpp, there is function CBurningVideoDriver::draw2DRectangle ,if i just comment out all what in the #ifdef SOFTWARE_DRIVER_2_USE_VERTEX_COLOR , then, GUI start to works as should (i.e. normal color, normal transparency). Same as If i just compile burnings-video driver with #undef SOFTWARE_DRIVER_2_USE_VERTEX_COLOR : dwarf still green, but GUI is good.

Probably its all about setA8R8G8B8() , but simple byteswapping didn't help (or i just doing it all wrong).

[hendu]

Patch posted:
https://sourceforge.net/p/irrlicht/patches/318/

[kas1e]

Yeah ! Thanks hendu !

And there is some tasty screnshots running in fixed burning:

http://kas1e.mikendezign.com/aos4/irrli ... ple_02.jpg
http://kas1e.mikendezign.com/aos4/irrli ... ple_09.jpg

[kas1e]

Found some other issues with burning/endian Example 08-specialFx.

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

As can be seen something with floor, and only with it. Everythig else (shadows, colors, etc) - all is fine.

[chronologicaldot]

@hendu - Why are you bitwise-ANDing FIXPOINT_COLOR_MAX with itself?

[kas1e]

@chronologicaldot
He don't, he remove what was here before and which make burning video works wrong on big endians I.e. it was wrong for long time, just probably no one tested big endian versions of burnin video.