SDL Device correctly processing events?

[kas1e]

Btw, while we at it, is "quit" keys is something which handled by devices ? I mean, in SDL device we have handling of alt+f4 for close window for example, pressing on close gadget, but didn't have for "esc" key. Is it expected that its irrlicht coders will handle esc for exit on their own, or, it can be / should be added to the SDL device instead ? Or it specially not handled inside of irrlicht, as games will need menus/etc from where esc can be done without closing the actual app ?

[kas1e]

@CuteAlien

Is win32device do something in software mode, which may explain huge differences with results over sdl1 in software mode ?

For example check this out from my icore_i5. Checks in software mode, win32dev and sdl1dev:

Code: Select all

 
    Software Render mode:
 
    Example                         win32dev  SDL1dev
 
02.Quake3Map                           127       92      
03.CustomSceneNode                     915      283      
04.Movement                            534      236      
08.SpecialFX                           111       88      
09.MeshViewer                          220      121      
10.Shaders                             575      241      
11.PerPixelLighting                    123       93      
12.TerrainRendering                    176      124      
13.RenderToTexture                     369      193      
15.LoadIrrFile                         292      176      
16.Quake3MapShader                     121       82      
18.SplitScreen                          73       56      
20.ManagedLights                       500      231      
26.OcclusionQuery                      108       72      
 

Some examples have really huge difference. Its like, win32device even in software mode use some kind of acceleration or so. Or, SDL1 device in software mode just suck hard (or code of SDL device, or SDL itself ?)

I then do compare In opengl mode, and there instead SDL1device ones is faster than win32device ones ! Check this out:

Code: Select all

 
    OpenGL Render mode:
 
    Example                         win32dev  SDL1dev
 
02.Quake3Map                           962      1023
03.CustomSceneNode                    2864      2671
04.Movement                           2000      2071
08.SpecialFX                           859       911
09.MeshViewer                          700       887
10.Shaders                            1286      1457
11.PerPixelLighting                   1012      1141
12.TerrainRendering                   1108      1423
13.RenderToTexture                    1572      1915
15.LoadIrrFile                        1314      1835
16.Quake3MapShader                     504       610
18.SplitScreen                         396       480
20.ManagedLights                      1242      1290
26.OcclusionQuery                     2011      2152
 

But in case with OpenGL, it at least on the same level, about the same. Just by some reassons SDL1 is faster in few parts.

So, question is: why it software mode, win32device just crash sdl1 device , and why in opengl mode, sdl1 device won over win32 device

But more interesting differences in software mode.

[CuteAlien]

ESC code should be handled by coders. Alt+F4 is a system key (so depends on your OS if that works - I have for example no idea about Amiga there... ). We didn't add ESC key handle to example to keep them as compact as possible.

I don't know about speed-differences. Did you check if double-buffering is enabled? Win32 device doen't do anything specific for software device to my knowledge.

[kas1e]

@CuteAlien

I don't know about speed-differences.

There definately something wrong happens with SDL rendering when its in software renderer. I also tested now on linux, with just "X11 device" vs "SDL1" device, and results are the same again : in opengl mode, its more or less the same results in both cases (still, SDL1 version also there faster a little, same as on win32). And in software mode its again some unreal difference, see:

Code: Select all

 
Software Rendering on Linux:
 
   Example                         x11dev    SDL1dev      
                                  
02.Quake3Map                        240       155        
03.CustomSceneNode                 1288       322        
04.Movement                         826       288        
08.SpecialFX                        180       133        
09.MeshViewer              <segm. fault>   <segm.fault>  
10.Shaders                          715       281        
11.PerPixelLighting                 244       166        
12.TerrainRendering                 290       180        
13.RenderToTexture                  602       261        
15.LoadIrrFile                      419       214        
16.Quake3MapShader                  180       118        
18.SplitScreen                      140        94        
20.ManagedLights           <segm. fault>   <segm. fault> 
26.OcclusionQuery                   319       168        
 

See, its again some unreal difference in x11device and in SDL1 device (what is also intersting to see ,that on the same hardware, but on Linux with X11 device, everything faster than on windows with win32 device, noticable).

So it seems, that while X11 device probabaly the fastest realisation of all devices in irrlicht in software mode, it seems that with SDL1device something wrong in whole.

In opengl mode all fine, SDL1 everywhere faster (through, kind of strange, as native devices should be faster imho, but difference not that much, so its ok).

I then tried SDL2 version, to see, if in software mode i will have the same big differences between native win32 and x11 devices, and yes, still it suffer from the same issue : too slow in software mode in compare with win32 and x11 devices.

Did you check if double-buffering is enabled? Win32 device doen't do anything specific for software device to my knowledge.

You mean that double buffering in SDL1/SDL2 should be enabled or instead disabled ? At least in SDL1 it seems enables for software mode, but i tried to comment out that line, and it make no differences.

[CuteAlien]

OK. But sorry, I really have no idea. Might profile at some point, but currently struggling with some shaders and too tired.

(On Windows you can give VerySleepy a try - it's a nice simple profiler, but you have to compile engine with release + pdb enabled for useful data)

[kas1e]

@CuteAlien
Added some basic support of opengl for SDL2 device too in my port:
https://github.com/kas1e/Irrlicht/commi ... 8dec7b2c6e

So , with SDL2 (at least on amigaos4 side), software rendering faster on 3-5 fps everywhere , and in opengl mode faster on 1-2 fps everywhere.

Through i have hard time with that "resizing". I.e. how to handle it in SDL2 properly.. In SDL1 we have:

Code: Select all

 
void CIrrDeviceSDL::setResizable(bool resize)
{
  if (resize != Resizable)
  {
    if (resize)
        SDL_Flags |= SDL_RESIZABLE;
    else
        SDL_Flags &= ~SDL_RESIZABLE;
    Screen = SDL_SetVideoMode( 0, 0, 0, SDL_Flags );
    Resizable = resize;
    }
  }
 

As i understand, there that thing which broken gadgets and stuuff (Screen = SDL_SetVideoMode( 0, 0, 0, SDL_Flags );) , recreate window on the same place, just with other gadgets. For SDL2 i was in hope to do something like this:

Code: Select all

 
void CIrrDeviceSDL2::setResizable(bool resize)
{
    if (ScreenWindow && resize != Resizable)
    {
        SDL_SetWindowResizable(ScreenWindow, (resize?SDL_TRUE:SDL_FALSE));
        Resizable = resize;
    }
}
 

But that will works only on win32 and linux, as most of time on other systems that SDL_SetWindowResizable is not implemented.

So, maybe instead, just close and open window with new flags ?

Maybe even in SDL1 version, instead of Screen = SDL_SetVideoMode( 0, 0, 0, SDL_Flags ); , we can just close window, and reopen it again with SDL_RESIZALE flag and attach opengl context again ?

Or, maybe you can point out, where we can add resizable flag to the device creation parameters , so i may try it on 1.8.4 version as well

[CuteAlien]

The problem with closing and re-opening is that all opengl resources (textures mostly) are no longer valid afterwards.

[kas1e]

Maybe it possible to recreate them all, again, just like at begining? I.e. we close window, and then again initialize all opengl resources, and re-open window with resize gadget.
Sure that ugly, but then it only happens one time at start.

But imho, some global flag, or "add resizable flag to the device creation parameters" are way to go (and with SDL1 , and even later with SDL2, imho). Because why need to reopen things, when it can be just opened as it should be right from the first open. Just device need to know it.

Sure, its not for 1.8.4 trunk, but then let 1.8.4 be as it was, everything new already in 1.9.0 only, so one more good change will to harm (and i can backport it to local version of 1.8.4 on my hardware easy i think).

[CuteAlien]

No, we can't re-open them. As we can't know often how they are created (you can use a random-generator to create a texture - or the user might have painted it).

I've been setting up my new Debian system last days (took a while, system was slow at first, but guess good enough to work with it again now I've moved it to SSD). So will try today to setup a test environment for SDL1 with Linux. I likely will fix it on Windows for Irrlicht 1.8 by keeping resources intact with the trick from the guy I linked above. And then add a flag on Irrlicht 1.9.

[kas1e]

Yep sounds like a good plan ! Will help with tests for both 1.8.4 and 1.9.0 , thanks !

[kas1e]

@CuteAlien
I see you add to 1.8.5 win32-fix , will test it tomorrow.

Trying to understand now where is 1.9.0 branch placed , is this ogl-es branch are 1.9.0 , or , that what is added now to 1.8.5 are will be 1.9.0 ?

[CuteAlien]

Yeah, added the win32 fix on 1.8. Not sure if I really do add the flag for resizable at startup to 1.9 as it likely works now already for SDL1. But I haven't looked at SDL2 yet - can you change resizable/not resizable on systems which don't support SDL_SetWindowResizable in SDL2 at startup? In that case I guess we'll need it.

About branches:
1.8 branch is bugfix branch for already released version. If I do an 1.8.5 that will become it. It only gets bugfixes which don't break compile or binary compatibility (so people can replace the dll by a new dll without recompiling their app, but also can recompile their app with new version without getting compile problems).

svn trunk is the main development branch and will become Irrlicht 1.9. I'll merge the 1.8 patches into it next week.
ogl-es is another branch, which is currently not that much in the works, but I'll merge patches from trunk into ogl-es as well. The plan for that one is getting it back into trunk some day.

[kas1e]

The problem of keeping it as it without adding a flag mean that it only fixes win32 build : for all other builds (like, amigaos4, aros, morphos, any other more or less obscure os) it still will have that bug.
I of course may try to find i way doing the same on other oses, but you there use WGL which also no other oses have, but only win32. So adding a flag will help both : and SDL2 and SDL1 when it not on win32/linux

But I haven't looked at SDL2 yet - can you change resizable/not resizable on systems which don't support SDL_SetWindowResizable in SDL2 at startup? In that case I guess we'll need it.

The reasson why SDL_SetWindowResizable is not implemented on other than win32 and linux oses, is that you can't change resizable/non-resizable in realtime

[kas1e]

@CureAlien
Tested r5866 on win32: yes, all examples works fine now , gadgets here, no distortions anymore, etc. Also mouse focus seems fine too.

But sadly that workaround for sharing-of-ogl-context is only for win32, for all others the same issue still Maybe you still consider a flag at least for 1.9.0 ? So, then for first all oses will benefits (and with sdl1 and with sdl2), and for second you can remove then that win32 workaround as well, so code will be cleaner.

[CuteAlien]

Yes, flag will come. Sorry, planned doing that earlier this week, but didn't work out. It's some work as it involves using that flag then also for other drivers and that also needs some testing.

But the win32 workaround should stay as it works as it should now. I don't have another platform right now where it fails as it works on Linux without need for the workaround. Didn't test WebGL so far and don't have other SDL platforms to test here. If setResizable causes troubles on other platforms we support (aka Android, WebGL, OS X, Linux) I can add defines to disable it there, so it will do nothing. For Amiga OS you can do the same (I suppose you have some defines to detect it).