Is BURNINGVIDEO bigendian aware?

[kas1e]

Hi all,

Just trying to port IrrLicht 1.8.4 to some obscure ppc-platform which have posix kind support, with using of SDL manager, and while Software Renderer works fine,i can't make to work BURNINGVIDEO renderer. I build it as default with BURNINGVIDEO_RENDERER_BEAUTIFUL , and that what i have for examples 03 and 04:





I.e. everything kind of works, just colors borks.

I tried also build with BURNINGVIDEO_RENDERER_FAST and BURNINGVIDEO_RENDERER_ULTRA_FAST , in both cases compilation fails. I.e. if i do:

#undef BURNINGVIDEO_RENDERER_BEAUTIFUL
#undef BURNINGVIDEO_RENDERER_ULTRA_FAST
#define BURNINGVIDEO_RENDERER_FAST

Then:

Code: Select all

 
CTRTextureBlend.cpp:341: error: no matching function for call to 'getSample_texture(irr::tFixPoint&, irr::tFixPoint&, irr::tFixPoint&, irr::tFixPoint&, irr::sInIternalTexture*, irr::tFixPoint, irr::tFixPoint)'
 
SoftwareDriver2_helper.h:808: note: candidates are: void irr::getSample_texture(irr::tFixPoint&, irr::tFixPoint&, irr::tFixPoint&, const irr::sInternalTexture*, irr::tFixPointu, irr::tFixPointu)
 

If i do:

#undef BURNINGVIDEO_RENDERER_BEAUTIFUL
#undef BURNINGVIDEO_RENDERER_FAST
#define BURNINGVIDEO_RENDERER_ULTRA_FAST

Then, before the same kind of errors arise (i.e. those from CRTRtexture,etc), i also have at first error about:

Code: Select all

 
CTRNormalMap.cpp: In member function 'void irr::video::CTRNormalMap::scanline_bilinear()':
CTRNormalMap.cpp:288: error: 'inversew' was not declared in this scope<builtin>: recipe for target 'CTRNormalMap.o' failed
make: *** [CTRNormalMap.o] Error 1
 

I tried also OGLES2 branch from SVN (in hope there can be fixes since 1.8.4 release), but that give me the same results.

[kklouzal]

Someone please correct me if i'm wrong but I believe BurningVideo is essentially depreciated and has been stated elsewhere on the forum that some features are broken in current releases.
Not sure if it has anything to do with your particular issue however you may want to stick with the software renderer?

[kas1e]

Someone please correct me if i'm wrong but I believe BurningVideo is essentially depreciated and has been stated elsewhere on the forum that some features are broken in current releases.
Not sure if it has anything to do with your particular issue however you may want to stick with the software renderer?

As i see Burning video is more accurate (at least in the examples provided with irrlicht). For example, example2 - quake map, you may try to run on Win32 binary from archive (bin/Win32-VisualStudio/02.Quake3Map.exe), and choise software render : all is broken. And burning video render : all is fine.

What make me think that burning video at current stage is better, just i can't build anything except BURNINGVIDEO_RENDERER_BEAUTIFUL, so can't check if all other options give me the same strange-colors result (to see if it general problem, or only BURNINGVIDEO_RENDERER_BEAUTIFUL).

[CuteAlien]

Hm, compile-errors got fixed in Irrlicht trunk, but I guess that never got back-ported to 1.8. But I don't expect it will help for this case anyway. I don't know about big-endian, but if it fails it's unlikely to get fixed on this platform. Burnings is not deprecated, but also not really under development.

The other software driver is mainly useful for quick UI stuff (aka setup-windows before real app starts) but has no full 3D support (like clipping). It supports enough 3D to be used for preview-displays. Burnings on the other hand is full 3D driver. Basically we keep them both around as they usually don't cause many troubles and I know some people which are still using them.

[kas1e]

@CuteAlien

Hm, compile-errors got fixed in Irrlicht trunk, but I guess that never got back-ported to 1.8. But I don't expect it will help for this case anyway. I don't know about big-endian, but if it fails it's unlikely to get fixed on this platform. Burnings is not deprecated, but also not really under development.

Yeah, you are right. I just downloaded ogl-es branch , and can compile with all 3 burning's versions, it didn't fix issues, just make them different BEAUTIFUL looks the same as from 1.8.4, but FAST and ULTRA_FAST versions looks like this:




Sorry CuteAlien, but if you doesn't mind,can you answer some lame questions about irrlich ? There are:

On that platform where i work now, we do not have opengl at all, i.e. we have, just some limited, 1.3 version, no glsl , so nothing good, i even can't run pure 01 example (when changed video::EDT_SOFTWARE on video::EDT_OPENGL of course). Its just render nothing:



Dunno, if it should be like this as no GLSL and too old opengl ? Or still it should draw something in any case ?


Anyway, we have full opengles2. It is standalone library, no OpenGL wrapper, no OpenGL init and then ogles, pure as pure , just ogles2. And that opengles2 added to our SDL2, which, IrrLicht didnt support at momemnt, as it support only SDL1 What the best and easy way for me:

a). waiting when IrrLicht will have SDL2 (can take years?)
b). trying to add ogles2 support to our SDL1
c). trying to write my native-os manager for IrrLicht, so avoid anything SDL or co, just pure native manager.

And, maybe you can give some small description of what need to do to add my own window-manager, what it should do exactly, and how it best to add. So i may try and if all going well will be able to use ogl-es branch, with my native manager, and so avoid SDL in whole. Maybe there some skeleton somewhere, or "how to make your maneger for IrrLicht" txt somewhere .. I may for begining of course comment everything out, and use only "open window and render" functionality in that native manager, skipping joysting and movents and stuff.

I also may try to replace myself in IrrLicht SDL1 on SDL2, and so be able to compile what i need, but native-manager always better, and dunno if it didn't bring new issues I search whole IrrLicht on SDL_, and there is not that much, so probably replacing it on SDL2 shoould be more or less "easy" ?

And last one question (if you don't bored still):
I can't find in the ogl-es branch anything about SDL_OPENGLES or something, i.e. it seems at moment, IrrLicht code mean that OpenGL is main for initialisation of the SDL1, but in the system itself wrapper for ogles2 done ? Or, it just mean that in IrrLicht no SDL1 support for Ogles as moment, and only for native managers ?

Thanks for your time !

[CuteAlien]

Can you clarify what your platform runs? In one place you say you have no OpenGL at all. Then you say you do have OpenGL 1.3. And then you say you have OpenGL ES 2.0. I'm not really understanding right now what your platform (not Irrlicht) supports. From screenshot it looks like it should have the correct stuff to run opengl driver.

Example shot looks like 2d functions of driver work and 3d functions don't. But could maybe also have other reasons (I'm struggling to figure out some related problems currently myself). If that were ogl-es it could also be a non-working shader (as 2d/3d use different ones), but with OpenGL pure that can't be the problem.

If you search forum there will be some patches for SDL2 I think. Otherwise it's probably not hard to add (as it's mostly identical to SDL1). Then again saying something is not hard in programming usually means you'll spend a long time on it ;-)

SDL is used for window setup - as replacement for X11 or Win32 API's. While OpenGL or OGL-ES are about graphic card drivers. So you don't need SDL_OPENGLES. SDL creates some window handles while OGL-es needs some window handles - neither of them really cares about the other beside that I think. But I'm also still learning myself a lot about the interplay of drivers and devices in Irrlicht, so take my words with a grain of salt.

[kas1e]

@CuteAline

Can you clarify what your platform runs?

Its amigaos4, some obscure platform for diehards Specific hardware, PPC cpu (so big endian) and not big user base.

In one place you say you have no OpenGL at all. Then you say you do have OpenGL 1.3.

When i say no opengl at all, i mean that its sooo dated, so limited, that it can't be called opengl We call it MiniGL and it somewhere around 1.2 (while IrrLich say 1.3, when i run it) with limited set of minimal fucntions which enough to have Blender, some games, and stuff.

And then you say you have OpenGL ES 2.0.

Yes. That is situation because of limited resources. When we luckyly have radeonHD 2d drivers, and for it some layer 3D driver, then, we was in situation of choice: on what spend resources to make full OpenGL2 on top of it, or, going route "kind of for future", and make OpenGLES2. So, we make OpenGLES2, which, do not use OpenGL at all. I.e. it is standalone opengles2.library, which inherit with the system internals and 2d/3d drivers as it needs.

And as result, while we have such sucky opengl (i call it "we have no opengl at all"), we still have full opengles2 , which i want to use for IrrLicht.

I'm not really understanding right now what your platform (not Irrlicht) supports. From screenshot it looks like it should have the correct stuff to run opengl driver.

There very well maybe issues with that limited minigl driver, which have no GLSL or anything of that sort.. But as it integrated to our SDL1 already, and proven to be working by porting bunch of old 3d games, i was in hope it all will works, but it fail, and i just curious is it because of no GLSL, or because just bugs in driver But that not so matter, ogles2 is way to go anyway for me

If you search forum there will be some patches for SDL2 I think. Otherwise it's probably not hard to add (as it's mostly identical to SDL1). Then again saying something is not hard in programming usually means you'll spend a long time on it

) Two more weeks (tm)

If you search forum there will be some patches for SDL2 I think. Otherwise it's probably not hard to add (as it's mostly identical to SDL1). Then again saying something is not hard in programming usually means you'll spend a long time on it

Will try to search , thanks for pointer
EDIT: found, that one probably ? : http://octodadgame.com/SDL2OpenGL.patch

SDL is used for window setup - as replacement for X11 or Win32 API's. While OpenGL or OGL-ES are about graphic card drivers. So you don't need SDL_OPENGLES.

I just didn't get at moment that : if i open SDL1 window, with SDL_OPENGL, then, how can i use OGLES2 over that window ? Its just like kind of fake window just for handles, and ogles2 driver in IrrLicht "found" necessary window to draw in ? Then why there needs to put SDL_OPENGL flag at all, just to have some basic functionality which is the same for opengl and opebgles2 ?

Btw, as i see, currently ogles2 with SDL support done only for _IRR_EMSCRIPTEN_PLATFORM_ only , i.e. if i didn't set that value, i then :

Code: Select all

 
    case video::EDT_OGLES2:
#if defined(_IRR_COMPILE_WITH_OGLES2_) && defined(_IRR_EMSCRIPTEN_PLATFORM_)
        {
            video::SExposedVideoData data;
 
            ContextManager = new video::CEGLManager();
            ContextManager->initialize(CreationParams, data);
 
            VideoDriver = video::createOGLES2Driver(CreationParams, FileSystem, ContextManager);
        }
#else
        os::Printer::log("No OpenGL-ES2 support compiled in.", ELL_ERROR);
#endif
        break;
 

[CuteAlien]

Ah, OK, not really familiar with Amiga too much (I did go from C64 to DOS and skipped Amiga ^_^).
MiniGL looks like it should work, would have to debug which calls fail (basically adding testGLError() calls over the place and figure out why some calls fail).
There have been 2 different SDL2 patches around I think, that looks like one of them.
About SDL_OPENGLES... yeah, that one also confuses me. Maybe some way to let SDL do the context setup instead of doing that with EGL (EGL is kinda this general platfrom wrapper for OGL ES which should work on all systems, replacing older solutions like WGL for Windows and some others). Or maybe that SDL uses internally EGL again. I haven't digged deeper there yet.

But you are right - our SDL driver only works with ES2 on emscripten so far. Reason is pretty trivial - no one tested it yet in another way. Emscripten patch came in just in last half year and so this was the first time we used SDL with ES2. If someone says those lines also work without emscripten I'll change it (mabye I can even test it soon, but right now working on another problem).

[kas1e]

About SDL_OPENGLES... yeah, that one also confuses me. Maybe some way to let SDL do the context setup instead of doing that with EGL (EGL is kinda this general platfrom wrapper for OGL ES which should work on all systems, replacing older solutions like WGL for Windows and some others). Or maybe that SDL uses internally EGL again. I haven't digged deeper there yet.

All in all, current ogles2 in IrrLicht mean to have EGL in any case, then. Its still l
ooks like hack of course, as why need to call EGL, in SDL device. Specially if one disable EGL, to have SDL Even if i remove _IRR_EMSCRIPTEN_PLATFORM_, it is still have that "ContextManager = new video::CEGLManager();" line in initialisation, which mean i need to reimplement it somehow or to SDL2 , or , dunno, to something native on my system.

For sake of tests, i remove all _IRR_EMSCRIPTEN_PLATFORM_ in the CirrDeviceSDL.cpp, and comment out those 2 lines:

Code: Select all

 
    case video::EDT_OGLES2:
#if defined(_IRR_COMPILE_WITH_OGLES2_) //&& defined(_IRR_EMSCRIPTEN_PLATFORM_)
        {
            video::SExposedVideoData data;
 
            //ContextManager = new video::CEGLManager();
            //ContextManager->initialize(CreationParams, data);
 
            VideoDriver = video::createOGLES2Driver(CreationParams, FileSystem, ContextManager);
        }
#else
        os::Printer::log("No OpenGL-ES2 support compiled in.", ELL_ERROR);
#endif
        break;
 

And, IrrLicht eat that, and compile librry for me.. So .. only problem then its that lines:

Code: Select all

 
            video::SExposedVideoData data;
 
            ContextManager = new video::CEGLManager();
            ContextManager->initialize(CreationParams, data);
 

And how to rewrote them on pure SDL(2), or on native code on my system ..

Then i will need replace SDL1 on SDL2, and .. fix the crashes )

Or maybe that SDL uses internally EGL again

That should't be imho, as for what .. SDL kind of abstract from all of this should be .

[hendu]

For the fastest way to get things running, use Mesa's software renderer(s) with irr's GL driver.

[kas1e]

@CureAlien

After discussing here: http://irrlicht.sourceforge.net/forum/v ... =4&t=52175
Can say that path from Odomex are hardcoed for opengl use only. I.e. there is no software rendering switches/ifdefs . Probably that no go to apply to IrrLicht main repo, as then noone will be able to use Software and BurninVideo drivers with that SDL2 patch.

Maybe there was another, more "friendly" and full ?:)

[kas1e]

@hendu
Check PM plz

[hendu]

Replied. One thing about example 1 on MiniGL though, the texture is non-power-of-two, which MiniGL may not support being so old. Try resizing the texture to power-of-two before giving up on MiniGL.

[kas1e]

@Hendu
Thanks for idea, just firstly want to make burning's video working. Just for sake of more info, there is screenshot of how it looks like when i run 02 quakemap example on burning video renderer:



As i see, everything in place, geometry, textures, everything, just colors borked, which remind me that "color wrong byte order" , when it swapped somehow, but can be wrong, no expert there of course..


And , example 09 : Meshviewer



So, GUI also affected. Model as well, background texture not affected as well as logo not affected. Any idea ?:)

At least some bounds in which files problem can be. I grep for all files who do burningvideo code, there is about 25 of them, so to reduce those ones to few will be good start at least

[CuteAlien]

Did you enable __BIG_ENDIAN__ by the way? It's in IrrCompileConfig and as we haven't tried supporting Amiga so far it's probably not enabled for that by default.