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

You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers.
No questions about C++ programming or topics which are answered in the tutorials!

Re: Building Irrlicht sharedlib from OGL-ES branch on Linux-

Postby okuoku » Sun Apr 15, 2018 7:30 pm

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-generic-sdl/blob/af608e1362f7d50fce3846cf43f023fc9cbd6680/source/Irrlicht/CIrrDeviceSDL2.cpp https://github.com/okuoku/irrlicht-generic-sdl/blob/af608e1362f7d50fce3846cf43f023fc9cbd6680/source/Irrlicht/CIrrDeviceSDL2.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-generic-sdl/blob/af608e1362f7d50fce3846cf43f023fc9cbd6680/source/Irrlicht/CIrrDeviceSDL2.cpp#L38 ).
User avatar
okuoku
 
Posts: 2
Joined: Sun Apr 15, 2018 12:05 pm
Location: Tokyo

Re: Building Irrlicht sharedlib from OGL-ES branch on Linux-

Postby hissingshark » Mon Apr 16, 2018 7:48 am

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.
User avatar
hissingshark
 
Posts: 13
Joined: Mon Jan 08, 2018 11:58 am

Re: Building Irrlicht sharedlib from OGL-ES branch on Linux-

Postby hissingshark » Tue Apr 17, 2018 11:26 pm

@okuoku
Sorry I missed your post first time around.
okuoku wrote: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.
User avatar
hissingshark
 
Posts: 13
Joined: Mon Jan 08, 2018 11:58 am

Re: Building Irrlicht sharedlib from OGL-ES branch on Linux-

Postby okuoku » Wed Apr 18, 2018 9:51 am

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-generic-sdl/tree/sdl2sharedlib - 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...
User avatar
okuoku
 
Posts: 2
Joined: Sun Apr 15, 2018 12:05 pm
Location: Tokyo

Re: Building Irrlicht sharedlib from OGL-ES branch on Linux-

Postby hissingshark » Wed Apr 18, 2018 8:06 pm

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.
cpp 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
cpp 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?
User avatar
hissingshark
 
Posts: 13
Joined: Mon Jan 08, 2018 11:58 am

Re: Building Irrlicht sharedlib from OGL-ES branch on Linux-

Postby CuteAlien » Wed Apr 18, 2018 9:11 pm

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.
IRC: #irrlicht on irc.freenode.net
Code snippets, patches&stuff: http://www.michaelzeilfelder.de/irrlicht.htm
Free racer created with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
User avatar
CuteAlien
Admin
 
Posts: 8528
Joined: Mon Mar 06, 2006 2:25 pm
Location: Tübingen, Germany

Re: Building Irrlicht sharedlib from OGL-ES branch on Linux-

Postby hissingshark » Thu Apr 19, 2018 8:35 pm

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!
User avatar
hissingshark
 
Posts: 13
Joined: Mon Jan 08, 2018 11:58 am

Previous

Return to Advanced Help

Who is online

Users browsing this forum: No registered users and 1 guest