SDL Device correctly processing events?

[CuteAlien]

Strangly the workaround for Windows didn't even work in trunk. I noticed now I got a gray Window after doing that. No idea why ... the SDL device code should be similar in that regard to Irrlicht 1.8. Maybe it even works just randomly in 1.8?

Anyway - I removed that code again in 1.9 (trunk) and added a flag now which can be set on device creation (SIrrCreationParameters.WindowResizable). And setResizable on Windows + GL will now simply do nothing. Could be that the "do nothing" part has to be added in more platforms. Can do so if I get informed about problems.

The new flag is not yet supported throughout, still have to figure out how to set it in X11 on window creation (will try that later on today probably).

[kas1e]

Thanks !

Through, seems i just dind't understand the purposes of Flag My throughs was that once flag is added, there will be no needs for custom hacks for each OS as we have with that "wgl-share-context" hack for win32.

I mean, making a flag tell the device creation if window created is resizable or not from begining, so, we will have no needs to have in the SDL code call to "setresizable", as it will be handled before , and so no needs for hacks and will works on all oses. Right ?

If so, did i understand right, that new Flag is supported now for SDL and can be tested on other platforms, but you still need to add it for X11 and check why it fail on Win32 ? Or it didn't fail on win32, what is fail is previous wgl-share-context hack (if so, who care that can be skipped as there will be no needs in that hack).

Will test it now anyway, thanks again !

[kas1e]

Ok brief test with adding of flag make all looks the same as before : no gadgets attached.

The i just comment out the same as for win32 calling of code from setResizable() (same as for win32 currently doing simple return) , and that leat to create a window without resizing gadget.

Like, it still want setResizable call, and still didn't create window with resizable flag from begining by some reassons.

So i added printfs to that block:

Code: Select all

 
    if ( CreationParams.Fullscreen )
        SDL_Flags |= SDL_FULLSCREEN;
    else if ( Resizable ) {
        printf ("resizable set, right ?\n");
        SDL_Flags |= SDL_RESIZABLE;
    }
    if (CreationParams.DriverType == video::EDT_OPENGL)
        SDL_Flags |= SDL_OPENGL;
    else if (CreationParams.Doublebuffer)
        SDL_Flags |= SDL_DOUBLEBUF;
    // create window
    if (CreationParams.DriverType != video::EDT_NULL)
    {
        // create the window, only if we do not use the null device
        createWindow();
    }
 

And i didn't see printf coming for example which should be resized. Like if (Resizable) not true all the time still.
Like device->setResizable(true); from examples didn't set our new WindowResizable to true.


Maybe that explain why it didn't works for you in win32 too ?

I also to check the commit more carefull, and i see that by default in SIrrCreationParameters.h flag is added as "false", but i didn't see anywhere in commit that flag is used somewhere where it check if it should be set to TRUE or not. Or i just don't understand the code and it somehere done automatically ?

Or that flag should be set from IrrLicht examples now directly ?

[CuteAlien]

It's not the new flag that doesn't work on win32. But the "wgl-share-context" hack failed. It worked in 1.8. But it did _not_ work in trunk. At least here. I have no idea why. But that's why I removed that one completely again.

The WindowResizable flag is used in the SDL device constructor, like: Resizable(param.WindowResizable)

I can't fix setResizable, but I also see no reason to remove it. Often functions only work on some platforms, that can't be avoided in cross-platform development. So a solution where it does _nothing_ on platforms which don't support switching that flag after window creation is fine. So yes, the fix is - it should do nothing now on platforms where it failed before. That's all.

And on top of that there is the new WindowResizable flag which allows to still get a resizable Window on such platforms. It's not used yet in any example.

I'm currently also considering setting WindowResizable to true by default (which will change all Win32 apps, but setting to false did change all X11 app behavior... so I can't avoid breaking one of them and in the end - I think having windowed apps beeing resizable by default is probably nicer). I might add setting WindowResizable to true or false in some example as well.
But I'll probably put that on TODO for a few days, as I've got some other bugs to work on.

edit: On minor note - demo audio changed now in trunk.

[kas1e]

And on top of that there is the new WindowResizable flag which allows to still get a resizable Window on such platforms. It's not used yet in any example.

Ah, so, then , for those platforms which didn't works before correctly, i then instead of let's say device->setResizable(true) in the 05 example, should then do now something like device->WindowResizable(true) ? Or that flag need to be set from exmaples somehow different ?

ps: yeah, Demo example fixes fine too , thanks !

[CuteAlien]

That flag can be set when using createDeviceEx. It's part of SIrrlichtCreationParameters.

[kas1e]

createDeviceEx

Only createDeviceEx ? Pure createDevice not expected to work (i.e. should it be updated or not ?)

I anyway just checked it now like this: in 05 example i just replace that part of code :

Code: Select all

 
#ifndef __amigaos4__
    IrrlichtDevice * device = createDevice(driverType, core::dimension2d<u32>(640, 480));
#else   
    irr::SIrrlichtCreationParameters params;
    params.DriverType=driverType;
    params.WindowSize=core::dimension2d<u32>(640, 480);
    params.WindowResizable=true;
    IrrlichtDevice * device = createDeviceEx(params);
#endif
 

And so it works ! Resize gadget here, resizing works, and those gadgets in place where they should be

I even didn't need to remove setResizable(), it even works with it, but then for sake of safelety of course i need to comment it out as well to not do anything if it not need it.

Will try other examples as well (09 and 24), but i think all will be fine

ps. Probabaly documentation need to be updated as well later to not forget that new flag ?

[kas1e]

@CuteAline

So changed in all 3 examples which use do Device->setResizable(true) , (those are 05, 09 and 24) on usage of createDeviceEx + setting the new flag to True, and violla, all works via SDL1 as well, check this out:

http://kas1e.mikendezign.com/aos4/irrli ... et_fix.jpg

Thanks a bunch !

ps. Btw, i have a question: if i want for example create an another look of dialog-windowses (those used for toolbars, for "open" , "save as" , etc), what i need to change to create another style ? (i.e. i want to make our OS specific style for irrlicht, so it will looks more integrated to the OS)

[CuteAlien]

As mentioned - I still consider flipping the default to resizable true. But need to work on some other stuff first.

Ah... don't mix topics in forum-threads too much, just create a new one once in a while :-) But in short - you can do some stuff with skin-colors. More stuff with a custom-skin. And when that is not enough copy-paste the code of elements and create new elements. Or if you need specific patches you can also post them and I'll consider them.

[kas1e]

Aha ok for other topics.

But can we continue in that one about SDL1 bugs ? If so, i found one more : this time its about returning of the list of available modes. Easy check will be 21.Quake3Explorer example : if you run it over SDL device compiled , then in the list of VideoModes you have nothing : empty. But when you set mark "fullscreen" , and then do "set" , it swith to fullscreen and then have list of modes. For win32 device all video modes shown from begining.

I have the same kind of issue before with SuperTuxKart, when it didn't return all available modes from begining , so in supertuxkart they made some workaround for. But then i found that issues was because of SDL_ListModes(vi->vfmt, SDL_Flags); in the getVideoModeList : be it win32 sdl1 or amigaos4 sdl1 , in all cases, if you didn't provide SDL_FULLSCREEN flag to the flags when do that call, you then fail (both on win32 and on amigaos4, so i think its SDL1 itself works like that). I even create a simple test case with pure checking on SDL_ListModes, and yes, when there is no SDL_FULLSCREEN flag provided nothing returns. So to fix it for supertuxkart, i just doing that:

Code: Select all

 
//! \return Pointer to a list with all video modes supported
video::IVideoModeList* CIrrDeviceSDL::getVideoModeList()
{
    if (!VideoModeList.getVideoModeCount())
    {
        // enumerate video modes.
        const SDL_VideoInfo *vi = SDL_GetVideoInfo();
        #ifdef __amigaos4__
        // to get list of all modes works even in window moe
        SDL_Rect **modes = SDL_ListModes(vi->vfmt, SDL_Flags|SDL_FULLSCREEN);
        #else
        SDL_Rect **modes = SDL_ListModes(vi->vfmt, SDL_Flags);
        #endif
        if (modes != 0)
        {
            if (modes == (SDL_Rect **)-1)
                os::Printer::log("All modes available.\n");
            else
            {
                for (u32 i=0; modes[i]; ++i)
                    VideoModeList.addMode(core::dimension2d<u32>(modes[i]->w, modes[i]->h), vi->vfmt->BitsPerPixel);
            }
        }
    }
 
    return &VideoModeList;
}
 

Then i ried the same on 21.Quake3Explrorer example on win32 : and it works.

So dunno how hacky and right that fix is ..

Btw, also found that "gamma" didn't works in that 21.Quake3Explorer example, but then found that in SDL1 it didn't implemented. I.e. half-implemented, then commented with todo-question.

[kas1e]

And another error found related to getvideomode(). This time is combo : and code of 21.Quake3Examplorer and the way how SDL1 works and maybe OpenGL.

So, as i say to get list of modes you should for first have SDL_FULLSCREEN flag set, but then, its not that easy. For OpenGL mode, if you set 16 or 24 bits, it will not works and fill return you no modes too.
I tested it by single testcases on win32 and amigaos4 , and yes, if you have 16 or 24 bit modes set then you will have no list of modes. It should be 32.

To fix that we can go probabaly 2 ways:

1. fix just example and be done with it, i.e. replace in 21.Quake3Explorer "deviceParam.Bits = 24;" on "deviceParam.Bits = 32;".

2. fix it in CIrrDeviceSDL.cpp by adapting a bit createWindow() , but maybe better and easy just to fix example itself

It probabaly left unnoticed for win32 before because for first list of modes didn't works at all before (as no SDL_FULLSCREEN flag was set) and then there arise another bug about which i told now : when we compile all with SDL1 ,there still ifdef in main.cpp of example, where we still want DirectX. And so, even if we compile with SDL, when we run example, it says "sorry no directX, choice what you want else", and so you choice then OpenGL, and its automatically set bits to 32 since then ignoring those "24" from example. But if you remove that ifdef from main.cpp, then "24" bits taken in account and we fail to have list of screenmodes.

My bet, that will be esay to set 32 bit in example, and be done with it, without needs to touching anything else in irrlicht's SDL1 code itself. Only add there SDL_FULLSCREEN so to make listing of modes works.

[CuteAlien]

Thanks. I fixed the CIrrDeviceSDL::getVideoModeList in Irrlicht 1.8 (will merge to trunk later).
Can just add that flag always (videomodes are about fullscreen videomodes).

The example.. uhm... does strange stuff. I'm not really familar with that one yet, but on first check I simply can't see how any of the values you set there is actually ever used. From what I can see it seems to use the default values and ignore all other settings.
So using 16,24,32 bit as default - all is just a lucky shot depending on desktop settings of the user. And it all shouldn't matter as the fullscreen value does seem to be ignored and that value shouldn't even be used in desktop (according to documentation).
Not sure right now if I'm missing how it works or if that example simply wasn't ever finished (wouldn't be the only one). Sorry.. stuff from before my time, I figured out some parts by now, but sometimes I'm just as clueless as any other user of the engine :-)

[kas1e]

The example.. uhm... does strange stuff. I'm not really familar with that one yet, but on first check I simply can't see how any of the values you set there is actually ever used. From what I can see it seems to use the default values and ignore all other settings. So using 16,24,32 bit as default - all is just a lucky shot depending on desktop settings of the user.

All i can found at moment, is that if i have in example "deviceParam.Bits = 24;" , and comment out block about define for win32 to do "deviceParam.DriverType = EDT_DIRECT3D9;" (so it not fallback to driver-choice-in-console thing) , then with 24 bits it fail, and in CIrrDeviceSDL's getvideomode() list i can see that return from "vi->vfmt->BitsPerPixel" are 24 , and so it fail to list video modes. If i change in example to "deviceParam.Bits = 32" , then return from "vi->vfmt->BitsPerPixel" in CIrrDeviceSDL's getviodemode() are 32, and so didn't fail and list all modes.

That the same for both win32 and amigaos4 oses , so seems not random.

What i only didn't get at moment, is why when i have in example that block about "deviceParam.DriverType = EDT_DIRECT3D9;" in win32 ifdef, and when irrlicht compiled without directx support we fallback to driver-choice-in-console-thing : that all alrigth. And then, if we choice there opengl , then for win32 at least we have in CIrrDeviceSDL's getvideomode() return from "vi->vfmt->BitsPerPixel" are 32. Even if in example we have 24. I assume just when some "reinitilisation" done, parameters resets somehow to some defaul and so we have 32.

I also tried to just comment out whole set of "deviceParam.Bits = XX;" , so to see what defaults are, and they are "16" bits. So, only when we set there 32 it make listing of modes works from begining.

And it all shouldn't matter as the fullscreen value does seem to be ignored and that value shouldn't even be used in desktop (according to documentation).

There is small test case i use:

Code: Select all

 
#include <stdio.h>
#include <SDL/SDL.h>
 
 
int main(int argc, char *argv[])
{
    SDL_Init(SDL_INIT_VIDEO);
        
    SDL_Surface *Screen = SDL_SetVideoMode(1024, 768, 24, SDL_ANYFORMAT | SDL_OPENGL);
 
    const SDL_VideoInfo *vi = SDL_GetVideoInfo();
    SDL_Rect **modes = SDL_ListModes(vi->vfmt, SDL_FULLSCREEN);     
    
    printf("SDL: flags are set to %x\n", SDL_FULLSCREEN);
    printf("bitserpixel = %d\n", vi->vfmt->BitsPerPixel);
    
    
    if(modes == (SDL_Rect **)0){
        printf("No modes available!\n");
        SDL_Quit();
    }
    
    if (modes != 0)
    {
        if (modes == (SDL_Rect **)-1) {
            printf("All mode available\n");
        }
        else
        {
            for (int i=0; modes[i]; ++i) {
                printf(" %d x %d x %d\n", modes[i]->w, modes[i]->h, vi->vfmt->BitsPerPixel);
            }
        }
    }
 
    SDL_Quit();
   
} 
 

So, when win32 desktop in 32 bits, i can only have list of modes when set 32 in SetVideoMode. If i set there 16 or 24 - no modes in return.

On AmigaOS4 where i have and 16 bit and 32 bit ones screenmodes, i have in return list of modes when set 16 or 32, but not when have 24 bits set.

In other words, all sounds logical : the return of the modes happens only of those ones we have.

And, that "deviceParam.Bits = 24;" from our example, can be just taken when we create sdl window, so SetVideoMode use it, which in return mean that we have "24" when do ask for list of modes. That why imho changing it in example from 24 to 32 are easer, than, for example, add some check in SDLDevice code. But then, how we can know if "24" can be used on platform of choice or not. Maybe some platforms have those modes , so some proper "check" need it, while probabaly change 24 on 32 in example will more than enough No proper bug fix, but still.

[CuteAlien]

OK, got it. I check now all bitdepths in the SDL device instead of just the one requested in the device. Which is same as it works for other devices. And yeah - these days (since Windows 8) we only will get 32-bit modes anyway. Irrlicht trunk actually set the new 32-bit default request already, just this example didn't. In Irrlicht 1.8 the default is still 16-bit so it would have failed not just in this example.

Thanks for the report!

Irrlicht trunk still need to be merged, will probably do tomorrow (I'm kinda done for today...).

[kas1e]

Yeah, on win32 it seems to works now. Just fail on my side with amigaos4, but i think it just issue with my SDL which need to be fixed. At least that simple test case works on win32:

Code: Select all

 
#include <stdio.h>
#include <SDL/SDL.h>
 
 
int WinMain(int argc, char *argv[])
{
    SDL_Init(SDL_INIT_VIDEO);
        
    SDL_Surface *Screen = SDL_SetVideoMode(1024, 768, 24, SDL_ANYFORMAT | SDL_OPENGL);
 
    const SDL_VideoInfo *vi = SDL_GetVideoInfo();
    
    SDL_PixelFormat pixelFormat = *(vi->vfmt);
    pixelFormat.BitsPerPixel = 32;
    SDL_Rect **modes = SDL_ListModes(&pixelFormat, SDL_FULLSCREEN);     
    
    printf("SDL: flags are set to %x\n", SDL_FULLSCREEN);
    printf("bitserpixel = %d\n", vi->vfmt->BitsPerPixel);
    
    if (modes != 0)
    {
        if (modes == (SDL_Rect **)-1) {
            printf("All mode available\n");
        }
        else
        {
            for (int i=0; modes[i]; ++i) {
            }
        }
    }
 
 
    /* Check is there are any modes available */
    if(modes == (SDL_Rect **)0){
        printf("No modes available!\n");
        SDL_Quit();
    }
 
    /* Check if our resolution is restricted */
    if(modes == (SDL_Rect **)-1){
        printf("All resolutions available.\n");
    }
    else{
    /* Print valid modes */
    printf("Available Modes\n");
    for(int i=0;modes[i];++i)
        printf("  %d x %d\n", modes[i]->w, modes[i]->h);
    }
 
    SDL_Quit();
   
}
 

But fail on amigaos4's SDL, so probably in terms of Irrlicht all fine, and to make it work on our side our SDL1 need to be fixed