request for next version: exposing style in Windows windows

[agamemnus]

I don't think there's a way to add a minimize button to an Irrlicht window (in Windows).

It's fairly important that my program has this.

I was told that I could add the "WS_MINIMIZEBOX" parameter to "style" when creating the window. (in Windows)

I found that tutorial 14 shows a way to render Irrlicht inside a Windows window, but that's a huge hassle.

I would like to suggest that the next version has this (turning on or off a minimized window button) as an option in the createDeviceEx function.

[DtD]

Make the window re-sizable. See the mesh viewer example.

[agamemnus]

Wow, that is very interesting!

Still, what about the off-chance that I want only a minimize button?

Anyway, serious follow-up:

When I resize the screen, it seems execution is paused (or maybe the redraw is)... any way to fix this?

[BlindSide]

Yes I wanted this a while back too, I'll look into adding some params although I'm not sure about the linux implementation.

[agamemnus]

Second follow-up question:

How do I correctly tell Irrlicht that a window has been resized if I resize it in Windows?

The screen width/height is updated, but the mouse events are still based on the old screen size... that means the middle of the screen in a 750x550 screen that has been resized to 375x275 is still "375, 275"!!!

[CuteAlien]

I think you have to call OnResize for the videodriver with the new size. Although I thought it handles that already. Will have to look when I'm back on Windows. Are you using Irrlicht 1.7.1?

[BlindSide]

On a related note, have we done the "System events" thing yet, CuteAlien?

I was discussing it with bitplane a few months ago...

[agamemnus]

I am using the compiled 1.7.1 DLL, yes.

Actually, never mind, looks okay.. it was caused by not updating the GUI with the new numbers properly.. (though I still haven't figured out how to do that!)

Still have one outstanding...:
"When I resize the screen, it seems execution is paused (or maybe the redraw is)... any way to fix this?"

[CuteAlien]

On a related note, have we done the "System events" thing yet, CuteAlien?

I was discussing it with bitplane a few months ago...

Hey now, don't mix thread-topics :-) But no, I haven't done those so far.

"When I resize the screen, it seems execution is paused (or maybe the redraw is)... any way to fix this?"

I think while resizing a Window is no longer seen as "active" so the isWindowActive check fails. I suppose you check for that probably in your main-loop. Maybe prevent rendering only for !isWindowMinimized (). Although you should probably at least render less often when it's not the active Window. It's a little tricky how to write a nice behaving 3D Window application...

[xDan]

You can change the style after the window has been created:

Code: Select all

    void cleanWindow()
    {
        HWND hwnd = reinterpret_cast<HWND>(app.getVideoDriver()->getExposedVideoData().OpenGLWin32.HWnd);
        ShowWindow(hwnd, SW_MAXIMIZE);
        
        // Maximised window with no close, minimise etc buttons.
        //SetWindowLongPtr(hwnd, GWL_STYLE, WS_BORDER|WS_MAXIMIZE|WS_VISIBLE);
        
        // Enable minimising, resizing and other things...
        SetWindowLongPtr(hwnd, GWL_STYLE, WS_BORDER|WS_CAPTION
                |WS_MAXIMIZE|WS_MAXIMIZEBOX|WS_MINIMIZEBOX|WS_SIZEBOX|WS_SYSMENU|WS_VISIBLE);
        
        SetWindowPos(hwnd, NULL, 0, 0, 0, 0, SWP_NOSIZE|SWP_NOMOVE|SWP_NOZORDER);
    }

...although it does mean there is a brief flash using the old style before it changes.

[agamemnus]

I think while resizing a Window is no longer seen as "active" so the isWindowActive check fails. I suppose you check for that probably in your main-loop. Maybe prevent rendering only for !isWindowMinimized (). Although you should probably at least render less often when it's not the active Window. It's a little tricky how to write a nice behaving 3D Window application...

As far as I can tell, I don't have that check. (I have isWindowMinimized, and it does not activate when resizing)

I added a counter+print to my loop and it stops incrementing it when I resize.

[CuteAlien]

That turns out to be not so easy to solve. Basically Windows enters a modal loop in certain situations like users clicking on the titlebar of a window, or resizing or moving a window. There's a thread on gamedev on this (http://www.gamedev.net/community/forums ... _id=488074), which basically proposes 2 approaches. Either start a timer as soon as that modal loop is started and update rendering in that timer or do use a second thread for the game-logic.

Not really sure if/how we should handle this in Irrlicht...

There is one thing I want to change for some time - and that is reworking the way the WndProc is handled currently, so that in the end Irrlicht offers default functionality but users can override and handle all messages. This would basically allow users to implement the timer-solution for this case themself. But not sure yet how we do that, although I think it will probably will have to work with some os-specific callback solution to handle all cases. Architecture proposals are welcome (Without thinking about it yet too much, I suppose a solution might be a data structure to expose OS-specific stuff which contains for Win32 an array of WndProc's which are called in the real WndProc).

That's something that would be useful in general. Then again using threads would probably be the cleaner solution - but I haven't thought yet how the architecture would have to look like in this case.

[BlindSide]

Well you can just update the render everytime you get the resizing windows message, CuteAlien. It may not update if the user holds the mouse down without resizing the window, I haven't tested that.

[CuteAlien]

Currently the users can't even do that, because run() never returns. With the change I proposed that would be possible, yes. Although showing new frames only when the user moves the mouse might not be enough in some games (not if you want to continue playing an animation for example).

[zet.dp.ua]

Threads are the best way to separate window message handling from the game loop. There are two possible solutions:
1. Create window in the "main" thread, create video driver in the "game" thread.
In this case the "while (device->run()) {...}" block internals must be replaced by some "game entry" class that can be allocated in the main thread, but initialized and updated in the game thread.
2. Create window in the "ui" thread, create video driver in the "main thread".

"ui" thread should just handle wndproc in the standard peekmessage loop and transfer all events.