Building Irrlicht sharedlib from OGL-ES branch on Linux-plat

[okuoku]

Uh, I faced the exact same situation(port Irrlicht on GLES2 without any existing windowing system support; that was UWP in my case https://github.com/okuoku/irrlicht-uwp ).

My choice was porting current SDL1 device to SDL2. https://github.com/okuoku/irrlicht-gene ... ceSDL2.cpp https://github.com/okuoku/irrlicht-gene ... viceSDL2.h . SDL2 already has decent abstraction layer on GLES2 + EGL so we don't have to do any heavy-lifting currently done in CEGLManager (My CSDLContextManager implementation is almost empty.. https://github.com/okuoku/irrlicht-gene ... L2.cpp#L38 ).

[hissingshark]

YES! I'd snuck in a NO_IRR_COMPILE_WITH_EGL_MANAGER_
Thank you.
It builds. Whether I can get it to work in the wild is another matter!
I need to see about detecting the local display resolution etc next as it's hardcoded for now.

[hissingshark]

@okuoku
Sorry I missed your post first time around.

SDL2 already has decent abstraction layer on GLES2 + EGL

Indeed, although I need a special build for my Mali GPU, but it works.
Minetest is still only getting the NULL video driver reported by my Irrlicht library so I'm still not there...

I'll take a serious look at what you've done there then with SDL2. Thank you for sharing your code/patch.

[okuoku]

I was too lazy to add SDL2 device on the Makefile.. Prepared two branches:

https://github.com/okuoku/minetest/tree/irr19 - Patched mintest that forcibly selects SDL2 + OpenGLES2 backend (+ Irrlicht 1.9 compilation workarounds)

https://github.com/okuoku/irrlicht-gene ... 2sharedlib - Patched Irrlicht 1.9 from ogl-es branch to build SDL2 version of Irrlicht (+ minetest compilation fix)

I had tried them with VirtualBox + Ubuntu16.04 but VirtualBox's OpenGL driver crashes as soon as initialized OpenGL surface.. Anyway, i hope these branches would make things clearer; source/Irrlicht/Irrlicht.cpp selects backend and minetest needs to be modified to feed preferred driverType(EDT_OGLES2 for us).

Unfortunately, I don't have any immediate plan to complete my SDL2 port beyond my use-case(UWP on Xbox). Feel free to pick my changes in case they're useful for you, as I just ducttaped SDL2 and Irrlicht...

[hissingshark]

Yeah, I've already tried building from your repo and it seemed more promising than that.

Last night I:

Fixed a few includes.

Added -lSDL2 and the CIrrDeviceSDL2.o for linking in the Makefile and removed all the X11 related lib linkage.
There was a rounding error function that MT wanted for type short and Irrlicht didn't have so patched that.
Process of iteration but eventually got it to build and MT to build against it!

EDIT:
LOL - I've just reviewed your changes and it's most of what I stayed up last night working out for myself...
Even the rounding error!

Thank you for taking the time to share your changes though!
Quite proud it proves my working was ok! But not sure that justifies the lost sleep...
Your use of sdl2-config was a much more professional approach.
I didn't get pulled up about the missing <time.h> on my system for some reason.

MT now advertises NULL and OGLES2 drivers available, which my non-SDL2 build failed to do as I reported yesterday.

Code: Select all

video_driver = ogles2

in the minetest.conf file has allowed me to select the correct driver.

Now I get a promising light blue screen at startup and:

2018-04-18 20:24:00: WARNING[Main]: Irrlicht: Could not open vertex shader program file: media/Shaders/COGLES2Solid.vsh
2018-04-18 20:24:00: WARNING[Main]: Irrlicht: Could not open pixel shader program file: media/Shaders/COGLES2Solid.fsh
2018-04-18 20:24:00: ERROR[Main]: Irrlicht: GLSL shader program failed to link
2018-04-18 20:24:00: ERROR[Main]: Irrlicht: L0100 A program cannot be linked unless there are any shaders attached to it
2018-04-18 20:24:00: WARNING[Main]: Irrlicht: Could not open vertex shader program file: media/Shaders/COGLES2Solid2.vsh
2018-04-18 20:24:00: WARNING[Main]: Irrlicht: Could not open pixel shader program file: media/Shaders/COGLES2Solid2Layer.fsh
2018-04-18 20:24:00: ERROR[Main]: Irrlicht: GLSL shader program failed to link

etc etc for all of the shaders.

So basically it can't find the media/Shaders folder. I see the

Code: Select all

 OGLES2ShaderPath("../../media/Shaders/")

defines it in SIrrCreationParameters.h,

But I can't fix that as I don't know where the path is relative to! Any ideas where?

[CuteAlien]

Can you set any absolute path? Meaning - do you have any filesystem?
Without... uhm, it's going to be tricky (simplest solution would probably adding shaders in strings directly in the code). Otherwise we have to think about something to support systems without filesystem (we usually can handle that already in most places, the trouble in this case is that users can't add an archive-loader first because this all happens in the createDevice).

edit: If we change it in Irrlicht, I think we should allow to replace existing materials. Which would be useful anyway. Given it's current structure it's slightly tricky to implement that in a non-messy way (material renderer always return their index in an array, which had reasons but leads to somewhat confusing code), but I guess we could have some function like IVideoDriver::copyMaterial(s32 origMaterialId, s32 targetMaterialId). Or call it replaceMaterial (or any other good name?). Then users could create more materials - and use those to overwrite existing ones which didn't load.

[hissingshark]

Of course! I'm over complicating things.
I completely overlooked trying an absolute path...

I've done that and Minetest starts. The entire screen is filled with sky blue, but the opening menu and clouds are only filling the bottom left corner of the screen. Progress!

[sunnystormy]

Blarg!

http://irrlicht.sourceforge.net/forum/v ... s2#p299506

Found this thread (which I authored a while ago, it seems... >_>). I wanted to compile Irr for Raspberry Pi and need to disable ES1 and make sure it found the EGL headers. "IrrCompileConfig.h" and "CEGLManager.h" are your friends.

[kas1e]

@All
Tried today to build SDL2 replacement from okuoku, from there : https://github.com/okuoku/irrlicht-generic-sdl
With appliing it to 1.8.4 irrlicht. All going fine, all what i had to do is only to remove _IRR_OVERRIDE_ from CIrrDeviceSDL2.h file in all places , so all compiles fine for 1.8.4 then.

So, then i tried to build 2 different versions of 01-helloworld example via EDT_SOFTWARE : one with sdl1 code coming with 1.8.4 , and one with sdl2 code coming from link above.

As result, SDL2 version SLOW LIKE HELL. It's like doing something wrong, or something with timing, or dunno what. Both mouse and rendering slower than in SDL1 variant a lot.

I then tried to build 02-quakemap (So to see fps), to run on some 10 years old notebook (1.6ghz amd) and to test it in software mode, and result are:

sdl1 (1.2.15): 34 fps
sdl2 (2.0.9): 14 fps

That on WinXP.

Then i tried to run it on some more or less modern hardware: Intel i5-7200U 2.71GHZ , and results are:

That on Windows10:

sdl1 (1.2.15) : 94 fps
sdl2 (2.0.9): 68 FPS


Something definately wrong with SDL2 code in that repo imho. Can't belive that SDL2 that slower (and by all other tests , it wasn't ever).

Probabaly issue can be because of CIrrDeviceSDL::present() realisation and how the surface and blitting done:

https://github.com/okuoku/irrlicht-gene ... ceSDL2.cpp

As i see there is some LockTexture after which come:

Code: Select all

 
SDL_Surface *copyto = SDL_CreateRGBSurfaceWithFormatFrom(
        pixels, Width, Height, 32, pitch, SDL_PIXELFORMAT_ARGB8888);
 

Then unlocking of texture, then SDL_RenderCopy() and so on.

Any ideas ?:)

[kas1e]

Futher checking with some other devs, show that in that SDL2 implementation it allocates (and frees) 2 surfaces per frame (which is no go of course). Instead, there should be just a pre-allocated streaming texture which gets updated once per frame and finally presented. So this implementation just looks very slow and pointless.

Probabaly it didn't affect OGL-ES rendering , but for software rendering that definately should be changed/fixed.

[okuoku]

Yup, i do aware that. Replacing that render path streaming texture would be required if you do any CPU rendering. (Relying GPU surface is particularly done to utilize GPU debug tools from vendors.)

In case you have to use 1.8 irrlicht + CPU rendering on SDL2 platform, perhaps sdl12-compat ( https://hg.libsdl.org/sdl12-compat ) is the way to go. It implements SDL1 API on SDL2; it still lacks some features on SDL1(palettes, CD-ROM, ...) but it should be easy to adopt on it.

[kas1e]

@okuoku
I fixed software rendering part, it should be just like this:

Code: Select all

 
//! presents a surface in the client area
bool CIrrDeviceSDL::present(video::IImage* surface, void* windowId, core::rect<s32>* srcClip)
{
 
    if (SDL_UpdateTexture(ScreenTexture, NULL /* update whole texture */, surface->lock(), surface->getPitch()) != 0) { 
        // SDL_GetError 
    } 
     
    if (SDL_RenderCopy(ScreenRenderer, ScreenTexture, NULL, NULL) != 0) { 
        // SDL_GetError 
    } 
    SDL_RenderPresent(ScreenRenderer); 
 
                
    return true;
}
 

And, CreateTexutre() should use SDL_PIXELFORMAT_ARGB1555 format, as Burning video seems anyway hardcoded to it (and probabaly software rendering too ?). Without locks , recopy of surfaces, etc. That way FPS are the same as with SDL1.