SDL Device correctly processing events?

[CuteAlien]

Uhm, I'm not sure if I ever run that one with audio enabled. Have to check :-) Thanks.

[CuteAlien]

Missing gadgets and example 24 seem to be related to same thing. For some reason the default-font is returning crap when used with SDL + OpenGL. It works for SDL + software drivers, so not a problem in the font. Couldn't find out yet what's going on will likely will continue hunting that one next week.

[kas1e]

At least you somewhere already

Also found some interesting thing about : i build irrlicht 1.8.4 for Linux (mint), with usage of SDL device, and, there _NO_ missing gadgets in the 09.Meshwiever example. Also example 24.CursorControl renders fine too ! So yes, both issues related, but then, it happens only with win32 and/or amigaos4 OS when used SDL+OpenGL, but didn't happens when use SDL+OpenGL on linux. Probably that can help to find out the roots ?

But good to know that its all just one single issue.

edit: maybe for linux there some other ifdefs used which didn't taken in account for win32/others , and those ones can give us a hint ?

edit2: also what i found, that in both, win32-gcc build on windows10, and linux build on mint , once you choice "Burning video" in any of example, it always segm.fault. But on amigaos4 for example are not, works as expected.

[CuteAlien]

Hm, didn't have the segmentation faults yet. But currently testing with VisualStudio (bit easier to debug than with gdb).

[CuteAlien]

This seems to be about setResizable. That calls SDL_SetVideoMode internally and after that things get randomly wrong. I suspect there should be a SDL-device specific changeRenderContext function in the OpenGLDriver as the other devices have those. But have to figure out first how SDL device gets any GL context (not an area with which I had that much to do before...)

[kas1e]

Interestingly why it works on Linux (with SDL device, without x11-device).. Maybe just luck..

[CuteAlien]

Yeah, maybe it ignores there a SDL_SetVideoMode call which doesn't change the resolution or so. Don't know. But commenting out that line makes it work here in trunk and in 1.8 ... and it makes somewhat sense.

[kas1e]

@CuteAlien
Yeah, you are right. Once i comment out that "Screen = SDL_SetVideoMode( 0, 0, 0, SDL_Flags );" in setResizable(), then gadgets back in 09.MeshViewer, and 24.CursorControl start to works too.

Through of course i can't resize 09.MeshViewer anymore after that commenting out.

And btw, when resizing fucntion in place originally (without commenting out that SDL_SetVideoMode call), it seems that this 09.MeshViewer also have that "white line border" as you say before about 05.UserInterface and 24.CursorControl. And they all too can be resized, and that white -border disappear after first resizing. But once i comment out that SDL_SetVideoMode call, then all those 3 examples can't be resized of course, but, there is also no white border anymore too. So white border line + that gadget-miss and co bugs are about the same SDL_SetVideoMode call seems so. Maybe SDL_FLAGS got messed somehow ?

[CuteAlien]

Not a simple problem to fix. The trouble seems to be that the opengl context is lost when the SDL_RESIZABLE changes. So all opengl resource have to be created new. Which in this case in the examples would be the default-font as that one is always created at that point.

Unfortunately I can't add resizable as a flag to the device creation parameters in 1.8 or I'll break binary compatibility for the DLL (it's no problem adding it in trunk/1.9). So I have no way right now to allow users to set this flag earlier. I'm actually not sure if SDL even guarantees that the OpenGL context will stay intact if that flag is set from the start, although it works here. I only found one thread discussing this on the web which hinted that it might fail with some SDL versions.
edit: I could maybe add a new global static which allows to create SDL with SDL_RESIZABLE. Thought also a somewhat ugly hack.

I found one workaround, thought it would only work for Windows and it's also slightly hard to add in a clean way without breaking binary compatibilitly (might be possible somehow, but will only fix Windows- or have to code it for all platforms somehow): http://www.bytehazard.com/articles/sdlres.html

Last solution would be to try to manually clean that texture (maybe checking if it's the only one so far) and creating it now. Ugly hack thought - and wouldn't work when setResizable is called later.

[kas1e]

Strange that on linux it behave ok. Like or context didn't lost and recreation didn't happens, or context lost, but recreation happens somehow fine.

Probably add resizable as a flag to the device creation parameters in 1.9 are way to go ? Then, those ones who need 1.8.4, can manually adapt it from 1.9 to their own local static builds.

[CuteAlien]

I find it rather strange it needs a new context on Windows when changing that flag. Stuff is handled different in SDL2 it seems. Should really add that one soon.

[kas1e]

Did i understand right, that issue is that irrlicht create SDL context without sdl resize flag, and then, recreate context this time with flag, and then opengl context looses ? If so, it sounds logical : you have sdl context and opengl attached to it. Then, old context die, you create new one, and of course there need to be opengl one recreated too. From another side, everything works, but not gui-gadgets.

From another side, why irrlicht didn't created by default as resized, i mean, if it known that it will be resized, why create sdl context without resizing gadget, and then only add it with forgotten opengl ?:) But if there is internal needs for, isn't possible before or after calling that command with 0,0,0 and resize flag, recreate ogl context again ?

[CuteAlien]

It's somewhat logical - except that for that flag it wouldn't really need to lose the GL context (other wrappers - like Irrlicht for example - can change that flag without giving up GL context).

And I won't know if it will be resized. Default in Irrlicht is - things are not resized unless that is requested (in games in the past you often had fixed resolutions, this has a bit changed since then, so the default made more sense in the past).

I already tried other way round - start resized and then remove that flag later. But that also breaks.

And I can't tell SDL earlier because there's no flag in Irrlicht device creation parameters for this. And that would be the place to tell earlier.

[kas1e]

Probabaly made CirrDeviceSDL2 will be faster and better for future than trying to fix&hack that issue. For SDL1 there can be a note that examples such as 09.Meshviewer and blabla behave wrong because blblal, so use SDL2 device if you want all be good.

I create amigaos4 port of irrlicht with amigaos4 changes (not sure if you want to add them to main repo at all):

https://github.com/kas1e/Irrlicht

You can see there i made a pleminar SDL2 support, just only in software mode , but at least it works the same by speed as SDL1 already. Of course need fine tuning, love and stuff. Also there need to add OpenGL support. And that probably will be easer and most of devs who use irrlicht will be happy at last with SDL2

[CuteAlien]

Yeah, SDL2 should be added. SDL1 isn't even really supported anymore. Thought if I can find some quick fix I'll still apply it ;-)