IrrLicht engine

[kas1e]

Hi ptitSeb ! :)

Sorry for bother you with another issue which very well maybe not related to gl4es itself, but while waiting for fixes in our drivers in amigaos4, i give a go and port IrrLicht engine as well over gl4es. So all compiles, links fine. But once i run some simple test case (which works of course via software rendering, etc), it crashes in the AmglGetIntergerv().

I.e. it should then come with GLSL checking, and have words "GLSL not available" (at least that i have on legacy opengl), or available (probably that it should be with gl4es ?). But instead it crashes:

4/0.Work:irrlicht/bin/> 01.HelloWorld_gl4es LIBGL: Initialising gl4es LIBGL: v1.0.5 built on Mar 2 2018 01:33:59 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Hardware test disabled, nothing activated... init_matrix(0x6b0b1bb0) LIBGL: Targeting OpenGL 2.0 LIBGL: Current folder is:/Work/irrlicht/bin/ Irrlicht Engine version 1.9.0 SDL initialized SDL Version 1.2.15 Using renderer: OpenGL 2.0 GL4ES wrapper: ptitSeb OpenGL driver version is 1.2 or better. << CRASH>>

I am almost sure, that its again some problems in our ogles2 driver (as i can see in log, that it crashes in the "AmiglGetIntegerv()", but maybe (only maybe), it can be something in gl4es as well ? Its even didn't throw any debug output from gl4es, as it crashes seems too early.

There is crashlog: http://kas1e.mikendezign.com/aos4/gl4es/irrlicht/crashlog_irrlicht_helloworld.txt

Maybe you have some ideas what it can be .. Thanks !

[ptitSeb]

It seems to me that Irrlicht is querying the OpenGL driver before creating the context. I guess it's gathering information to know which context to create.

All glGetString(..) function works in that mode (i.e. no context yet), but here, it's a glGetIntegerv(..) and I guess it's not handled internaly so the query is pass to the OGLES2 driver, that surely doesn't like query before a context is created.

I need to check wich value are queried. I'll look there: https://github.com/zaki/irrlicht/blob/master/source/Irrlicht/COpenGLExtensionHandler.cpp#L581 for the list...

[kas1e]

Oh sorry, false alarm, just compiled it with wrong sdl :) will delete report then

[kas1e]

It now compiles but produce the same kind of mess as it was with quake3 when used extensions, so probably everything should be on hold till that not fixed in our drivers.

sorry for bother :)

[ptitSeb]

Yeah, I was about to say that, that Irrlicht will use only glDrawArrays(...) and glDrawElements(...) for drawing.

I used a few days ago Irrlicht 1.8 (with X11/EGL backend) on the Pandora to try SuperTuxKart 0.8.1 with the GLES2 backend, and it worked fine (I just need to sue LIBGL_SHRINK=10 to reduce the size of the textures, they are too many of them for the Pandora).

[kas1e]

Just to avoid creatin another topic about Irrlicht engine, probably will be right to continue there..

So, while Daniel trying to find what issues with q3 is (still can't by some reassons), i run with our hack irrliht engine example, and it looks a bit wrong by colors.

There is original of how it should looks like: http://irrlicht.sourceforge.net/images/tutorials/001shot.jpg

And there is my one compiled with gl4es: http://kas1e.mikendezign.com/aos4/gl4es/irrlicht/irrlicht_helloworld.jpg

Probably something about endianes as well ?

Also curious about all those glXetProcAddress not founded.. Did you have the same ?

[ptitSeb]

The glXGetProcAddress errors are normal. It's just openGL extensions that gl4es doesn't handle.

The bad colors are probably some texture bigendian issues, so a log (just texture.c) would be helpfull.

(is it normal the sample thinks it's running on the burning software renderer and not the OpenGL one?)

[kas1e]

The bad colors are probably some texture bigendian issues, so a log (just texture.c) would be helpfull.

There is: http://kas1e.mikendezign.com/aos4/gl4es/irrlicht/irrlicht_hello_world_texture.txt

(is it normal the sample thinks it's running on the burning software renderer and not the OpenGL one?)

Yep, its just by default example are done for burning, but i replace in the example's code EDT_BURNINGSVIDEO on EDT_OPENGL, so it use opengl.

[ptitSeb]

Commit 90fd5c1bbe64e36927578b2456eaeb3a88aab8b6 should fix the texture issues.

[kas1e]

Yeah, it is :) Thanks ! Tested also Cadog (just to see if there wasn't regressions) - all is fine as well.

Tested also other example, and in terms of colors, there is another issue with 06.2DGraphics example. Have a look at how it should be: http://irrlicht.sourceforge.net/images/tutorials/006shot.jpg

And how it for me for now: http://kas1e.mikendezign.com/aos4/gl4es/irrlicht/irrlicht_2dgraphics.jpg

There is debug output from texture.c: http://kas1e.mikendezign.com/aos4/gl4es/irrlicht/irrlicht_2dgraphics_texture.txt

[kas1e]

That can be through not textures issues now, as that what i read in the header of example:

It shows how to draw images, keycolor based sprites, transparent rectangles, and different fonts. You may consider this useful if you want to make a 2d game with the engine, or if you want to draw a cool interface or head up display for your 3d game.

So can be endianes for pixel.c or something ?

[ptitSeb]

Does it work with MiniGL?

If I remember correctly, the Texture is read back, and then the color key is applied to make it transparent. I guess the colorkey is not detected correctly in the image because of the endianness.

[kas1e]

With minigl i even cant run irrlicht engine as it crashes a lot :) i can only compare with win32 version.

But that for sure endianes, as where is purple on my screenshot it should be tranparent, so alpha, and so probably just swaps done wrong.. But where :)

[ptitSeb]

No, the purple is the colorkey. It's not alpha at first. Look at the example code, you'll see:

        video::ITexture* images = driver->getTexture("../../media/2ddemo.png");
        driver->makeColorKeyTexture(images, core::position2d<s32>(0,0));

Open the 2ddemo.png and you'll see the purple is part of the image. The issue is with "driver->makeColorKeyTexture" that doesn't seems to make the colorkey transparent.

[ptitSeb]

Look in CNullDriver.cpp in Irrlicht source code. Both version of the method makeNormalMapTexture from class CNullDriver (that will be used in the OpenGL driver), use some masking of the colors that seems LittleEndian to me.

Stuff like const u32 refZeroAlpha = 0x00ffffff & color.color; should be const u32 refZeroAlpha = 0xffffff00 & color.color; I think. And same for if(((*p) & 0x00ffffff) == refZeroAlpha) that should be if(((*p) & 0xffffff00) == refZeroAlpha)

[kas1e]

Do you mean its endianes issues with irrlicht engine itself ?

[ptitSeb]

Yes, that's what I mean.

[kas1e]

Yeah, will check

[kas1e]

And probaably that one:

colorKey = 0x00ffffff & p[colorKeyPixelPos.Y*pitch + colorKeyPixelPos.X];

should be

colorKey = 0xffffff00 & p[colorKeyPixelPos.Y*pitch + colorKeyPixelPos.X];

too ?

[ptitSeb]

Yes, probably.

[kas1e]

Tried all of them: didn't help.

Also noted another issue, dunno if it the same for you or not, but it can be generall issue. Any example with GUI , have some problems with "tickboxes": just black quads.

Have a look at example (that 09.MeshViewer example): http://kas1e.mikendezign.com/aos4/gl4es/irrlicht/tickbox_gadgets.jpg

See in the menu all thoe black quads, while should be tickbox images. Also all dropdown menus also black quads. And in that whole example, transparency effect didn't work too.

Can be again irrlicht's endian issues of course, but maybe something about gl4es as well.

[ptitSeb]

Yes, probably the use of colorkey there too.

You should printf the values of the colorkey in Irrlicht, to see what they are and maybe get an hint of what is going on.

[kas1e]

What is interesting, is that this 06.2Dgraphics example give the same problems with burnings video renderer , but ok with software renderer. So its something which share burning and opengl renderers, but not software one.

[ptitSeb]

I just realized I copy/pasted the wrong methid name earlier. It's makeColorKeyTexture you should looking for, not the NormalMap thingy I pasted...

[kas1e]

That no problems, as anyway you post code strings from makeColorKeyTexture. Strange that didn't make differences, but that can be keept for later, in meantime tried to build SuperTuxKart 0.8.1 which is prove to works by you on gl4es.

Didn't you have any issues when building it ? I have an issue when running, it just crashe on SDL_GL_GetProcAddress by some reassons ..

[ptitSeb]

For the colorkey, you need to put some printf in Irrlicht, to print the extracted colorkey and see if it looks like 0xff00ff00 (should be pure pink in RGBA bigendian).

For SuperTuxKart, I didn't have much issue (not that I remember, but I used Irrlicht 1.8 for it). An error in SDL_GL_GetProcAddress? This function has no reason to crash, unless SDL/gl4es not properly initialized.

[kas1e]

I just build IrrLicht which come with 0.8.1, as it seems they modified it a bit ? Or you just build separately irrlicht 1.8, and then link against it and all works ?

[ptitSeb]

I used my own build, because I had put some NEON optimisation (AltiVec equivalent on ARM), but it's sipler to use supplied version indeed.

[kas1e]

It is probabaly something with scc/graphics/irr_driver.cpp from supertuxkart.

When i run supertux kart, i have that in output:

4/0.Work:supertuxkart> supertuxkart LIBGL: Initialising gl4es LIBGL: v1.0.5 built on Mar 8 2018 19:11:01 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Hardware test disabled, nothing activated... LIBGL: Targeting OpenGL 2.0 LIBGL: Current folder is:Work:supertuxkart Irrlicht Engine version 1.8.0 SDL Version 1.2.13 [info ] FileManager: Data files will be fetched from: 'PROGDIR:' [info ] FileManager: User directory is '.supertuxkart'. [info ] FileManager: Addons files will be stored in '.supertuxkart/addons'. [info ] FileManager: Screenshots will be stored in '.supertuxkart/screenshots'.

All modes available.

All modes available.

[warn ] irr_driver: The window size specified in user config is larger than your screen!

And then crash. I see there 2 times "all modes available", then some strange warn, and then crash.

While , when i run IrrLicht examples, i have that kind of output:

LIBGL: Initialising gl4es LIBGL: v1.0.5 built on Mar 8 2018 19:11:01 LIBGL: Using GLES 2.0 backend LIBGL: OGLES2 Library and Interface open successfuly LIBGL: Hardware test disabled, nothing activated... LIBGL: Targeting OpenGL 2.0 LIBGL: Current folder is:Work:supertuxkart Irrlicht Engine version 1.8.0 SDL Version 1.2.13

and then: LIBGL: Hardware test on current Context ... And so on , and then example runs.

Seems, something done in supertuxkart's irr_driver.cpp which my system dont like (or maybe my hacked SDL even ?). And so then no initialiation done, and then when it tries to do SDL_GL_GetProcAddress it crashes.

Invistigate ..

[ptitSeb]

Well, the sample does create a context properly, where supertexkart doesn't seems to. You need to put some printf to were it crash. But SDL_GL_PretProcAddress(...) doesn't do much things. It's just a function to give pointer adress. For it to crash probably means the SDL part is not initialized yet? Maybe supertexkart call SDL_Init() and SDL_Quit() many times?

[kas1e]

As far as i understand, supertixkart don't call SDL_INIT/SDL_QUIT at all, its IrrLicht which do call it from source/IrrLicht/CIrrDeviceSDL.cpp.

Those words about "All modes available." come from IrrLicht itself as well, from getVideoModeList(), which may fail by some reassons..

Will try to prinfs it all arounds

[kas1e]

Ok, found, its issues with our SDL_ListModes() didn't return list of modes. So i just cut that part off from their irrlicht engine, and manually do initialize opengl with 800x600, and so, it starts . But i have hard times with paths, its offten put doubles slashes, like "dir/dir//file" , etc. So need to fix that . At moment game starts, i have menu, can choice car, choice track, and then crash.

Also, on running, i do have warnins from irr_driver: "Too old GPU: using the fixed pipeline".

Did you have that as well ?

[ptitSeb]

Ah, issue with path... Good luck then.

Yes, the "Too old GPU" is normal. Irrlicht seems to want OpenGL 3 to activate shaders... So no shaders for now (and I have the same message on the Pandora).

[kas1e]

Well, if no shaders, then it mean there should be no problems for us :) Should just works then once i fix paths.

[ptitSeb]

In fact, I have double checked, and it's not Irrlicht that is complaining, SuperTuxKart. To activate glsl effect, it want glsl + npot texture. So to activate Shaders effect, you need to launch using LIBGL_FORCENPOT=1 and LIBGL_NPOT=2 Not sure all shaders works, I'm trying them now...

[kas1e]

Yeah, tested, indeed ! For me it fail anyway, as SuperTuxKart's shaders seems to be with arrays (which our warp3d do not support at moment), so that what i have:

irr_driver: GLSL supported. IrrDirver Temp Loger: GLSL shader failed to compile IrrDirver Temp Loger: ERROR: SPIR-V file is invalid/corrupt. Error log: Offset 00000087: Unsupported opCode: 28: OpTypeArray.

Through it skips that errors and continue loading in usual mode :)

[ptitSeb]

Ah yes, Array. Anyway, it works without shaders... (I have a black screen for now when the blur shader activate :( )

[ptitSeb]

Ok, got the blur effect in SuperTuxKart. But it's too slow to be usable on the Pandora, but at least it works!

[kas1e]

Have at least 5-10fps ?:)

[ptitSeb]

During the blur, nah, more around 2~3 fps... But the Pandora hardware is quite weak, so I was pretty sure it would be slow anyway. Rest of the game seems fine with shaders..

[kas1e]

More fixes the better anyway (if it was fixes in gl4es ?)

[ptitSeb]

Yes, I haven't pushed yet, but STK apply a GL_REPEAT command to a NPOT texture (the one from the FBO, before applying radial blur), and it's not supported on hardware that only have "limited_npot" support...

[kas1e]

By the way, i see in the glx/lookup.c at end:

ifdef AMIGAOS4

void aglGetProcAddress(const char* name) AliasExport("gl4es_glXGetProcAddress");

else

void glXGetProcAddress(const char name) AliasExport("gl4es_glXGetProcAddress"); void glXGetProcAddressARB(const char name) AliasExport("gl4es_glXGetProcAddress");

endif

Can we also enable that glXGetProcAddressARB for amigaos as well ? I mean will it even works on GLES2 backend ?

[ptitSeb]

Yes sure, it will work. It will work the same as aglGetProcAddress(...). You need that one?

[kas1e]

I mean if it will works over our ogles2 ? What is purpose of it ? Should it have something to be done in our ogles2 or it will works as it ? Sorry for dumb questions, just looses a bit there

[ptitSeb]

It will work. It's the same as the aglGetProcAddress that is already working with your integration in SDL. These functions are used in OpenGL to get Function Pointer of Extensions. Because extensions are optionnal, the function may or may not exist, so it cannot be hardcoded. That's why there is a mecanism to get the function point of a function, based on it's name. The function that does that is wglGetProcAddress in the Windows world, and glXGetProcAddress in the X11 world. SDL wrap thoses function in SDL_GL_GetProcAddress to abstract this plate-forme specific mecanism. On your SDL/Amiga, SDL use aglGetProcAddress for that. Enabling glXGetProcAddressARB will give you nothing more that aglGetProcAddress is doing (look at the code, both function are Alias of the same function), but it can be enabled if you need this kind of compatibility for some ports.

[kas1e]

In other words it will not make things worse , but only better ? I just not sure about those extensions. I mean i understand we have one (non ARB) getprocaddress functions for get pointers names. But with ARB it will probably mean, that our ogles2 should have all the same functions but with ARB ?

[ptitSeb]

I'll activate it latter, no problem, but I really doubt you need that one.

Anyway, this ARB function is exactly the same as the non-ARB. It's a gcc Alias, so it's a different name for the exact same function. And this function is pure gl4es, it doesn't use the GLES2 backend at all.

[kas1e]

Aha ok , thanks. More the better anyway :)

Btw, trying in the my SDL1 to use your aglCreateContextTags, i.e instead of :

hidden->IGL=IOGLES2->aglCreateContextTags i trying to do: hidden->IGL=aglCreateContextTags

(so it will take one from agl/agl.c). But then it just crashes..

[ptitSeb]

A crash in aglCreateContextTags? Strange. Can you have more detail on the crash? because the function is quite simple.

[kas1e]

I only can see how windows open for a second, then closes imnediately and crash. Probably there should be something done about that sharing of contexts.. As we open library in gl4es, but create context from sdl1 (and for creating context i had to include proto/ogles2, which may somehow inherit).

I will check more