@Madga
I checking all of this more, and i think it works with OpenGL just because SDL1 on SDL2 swap from Octomed done only for OpenGL. You may see in code that there is SDL_GL_CreateContext, which mean GL context in any case (so no software renderer possible with). Then , all the "swap buffers and stuff" given to OpenGL handler in IrrLicht. In previous, SDL1 (i.e. current) code, there is opengl context for opengl, and if no, then software rendering (so software and burning video will works). In other words, that patch can be used only by 3d party, if one want working sdl2 + opengl only.
GLFW integration problem
Re: GLFW integration problem
Can always add stuff later, so that's not necessarily a problem. I can't really go through it right now, SDL2 is on my todo, but I suspect not before summer.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: GLFW integration problem
@CuteAlien
Just to add for the future integration of sdl2 : I see how it done in second patch (that one , which was done for Android), there is all done better in terms of structure: CIrrDeviceSDL2.cpp and CIrrDeviceSDL2.h, used define _IRR_COMPILE_WITH_SDL2_DEVICE_ and when one want can use SDL1 , and another can use SDL2, that pretty good
Patch also "tries" to make it all right in terms of code (i.e. to support everything, include burning video, software renderer, etc), but for me, it is 2 times slower.
I mean, i compile r6000 with SDL1 , and have let's say 100FPS in 03-example, in both renderers (and in burning one, and in software one), but, when compile with that SDL2 patch , i have 39 fps with software rendered version and 72 fps in burning video version. Also in both cases with SDL2 patch something wrong: in burning video renderer backgrround not clears when move happens, and in software renderers there is 2 triangles rotates, instead of 1, and, with wrong colors (while in sdl1 version all is ok).
That second patch is really more complicated, and probably mess a lot of different things, and maybe even not big-endian aware as well.
So consider it to be not very well done. Speed should be (imho) if not the same as with sdl1, then even a bit faster, its SDL2 in end, should be better
Just to add for the future integration of sdl2 : I see how it done in second patch (that one , which was done for Android), there is all done better in terms of structure: CIrrDeviceSDL2.cpp and CIrrDeviceSDL2.h, used define _IRR_COMPILE_WITH_SDL2_DEVICE_ and when one want can use SDL1 , and another can use SDL2, that pretty good
Patch also "tries" to make it all right in terms of code (i.e. to support everything, include burning video, software renderer, etc), but for me, it is 2 times slower.I mean, i compile r6000 with SDL1 , and have let's say 100FPS in 03-example, in both renderers (and in burning one, and in software one), but, when compile with that SDL2 patch , i have 39 fps with software rendered version and 72 fps in burning video version. Also in both cases with SDL2 patch something wrong: in burning video renderer backgrround not clears when move happens, and in software renderers there is 2 triangles rotates, instead of 1, and, with wrong colors (while in sdl1 version all is ok).
That second patch is really more complicated, and probably mess a lot of different things, and maybe even not big-endian aware as well.
So consider it to be not very well done. Speed should be (imho) if not the same as with sdl1, then even a bit faster, its SDL2 in end, should be better