Win32 Window Creation
What I really need:
CreateWindow() ->
InitializeGraphicsAPI() ->
LoadGraphicsResources() ->
ShowWindow() /*Alright, I can see my rendered image immediately after the window gets showed.*/ ->
StartGameSimulation()
I'm not sure if this answers your concern:
In CreateWindow(), after the window is created, call:
ShowWindow( hWnd, SW_HIDE );
Your ShowWindow() is then:
ShowWindow( hWnd, SW_SHOW );
I'm not talking about the way the window appears that can be customized with WM_MAXIMIZE, WM_HIDE, etc.
I'm "asking" if is mandatory to show the window immediately after the window creation, and if I should initialize the Graphics API immediately after the WM_CREATE message. Since I did not ask the second answer in the main post, I'm going to assume the question now for clarifying the overall topic.
You may not have control over the windows message queue, but you have control over your own code. "Just" thread your loading and put up a window with a loading screen yourself that processes the message pump in the main thread while you load in a background thread. ("Just" in quotes because threading is hardly easy, but it's kind of what you want here)
I've put the main thread to do the Message Pump's job. In my case, it justs bufferize the Keyboard and Mouse events.
This is more like an optimization to not show the window until all graphics resources are loaded - not scene/game/whatever loading stuff that can be showed in a loading screen. It seems to be more intuitive to just show the window after, only after, all low level graphics are loaded. I can be wrong here, since I don't really know the standard way of doing this, only my way.
I'm not talking about the way the window appears that can be customized with WM_MAXIMIZE, WM_HIDE, etc. I'm "asking" if is mandatory to show the window immediately after the window creation, and if I should initialize the Graphics API immediately after the WM_CREATE message.
It's not clear what you mean by "customize" with regard to windows messages (WM_MAXIMIZE, WM_HIDE, etc.). Those messages in particular are used to display the window with it's current style in a particular state, normally responded to in the window procedure; those messages don't change the appearance style of the window.
See my post above. It's not mandatory to show the window immediately. You can hide the window after it's created and show it when you want to. Initializing the graphics immediately after the window is created isn't mandatory either, if there are other activities you want to do first.
Note: if your concern is user input, in particular, hiding the window may be the desired behavior. That is, without a displayed window, the implication to the user is that your app is not soliciting and will not process user input. If your other activities, before the window is shown, take very long, that violates the common expectation for the user that starting an app will result in some sort of visual feedback - at a bare minimum, an hourglass cursor; better a window telling the user what the app is doing - "Loading resources.. please wait" or the like.
Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.
You don't forget how to play when you grow old; you grow old when you forget how to play.
I'm not talking about the way the window appears that can be customized with WM_MAXIMIZE, WM_HIDE, etc. I'm "asking" if is mandatory to show the window immediately after the window creation, and if I should initialize the Graphics API immediately after the WM_CREATE message.
It's not clear what you mean by "customize" with regard to windows messages (WM_MAXIMIZE, WM_HIDE, etc.). Those messages in particular are used to display the window with it's current style in a particular state, normally responded to in the window procedure; those messages don't change the appearance style of the window.
See my post above. It's not mandatory to show the window immediately. You can hide the window after it's created and show it when you want to. Initializing the graphics immediately after the window is created isn't mandatory either, if there are other activities you want to do first.
Note: if your concern is user input, in particular, hiding the window may be the desired behavior. That is, without a displayed window, the implication to the user is that your app is not soliciting and will not process user input. If your other activities, before the window is shown, take very long, that violates the common expectation for the user that starting an app will result in some sort of visual feedback - at a bare minimum, an hourglass cursor; better a window telling the user what the app is doing - "Loading resources.. please wait" or the like.
By "customize" I mean, change the style of the window. I can't have an text being displayed - "Loading..." - until at least one shader is loaded - unless you're using Win32 methods for painting or pop-uping an new window; a child window is not what I want.
Why hide the window and then display it when the correct is to initialize everything low-level related to graphics first and after display it? For me - I'm not sure for everyone - this sounds more logical and the window won't stay opened while graphics resources are being loaded. Since no user input is received when the window is hide or not displayed at all, I'm going to state that the problem is solved. Thank you.
The correct thing to do here would be to display a splash screen, so the user knows that your application is launching, while at the same time giving you time to prepare your assets for initial scene startup.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
If your application takes a while to start up, and you are not displaying a window indicating that things are launching, then most users are going to assume "something is wrong" and try and launch it again.
The correct thing to do here would be to display a splash screen, so the user knows that your application is launching, while at the same time giving you time to prepare your assets for initial scene startup.
From the user point of view that's make sense. I see. Thank you.
Why hide the window and then display it when the correct is to initialize everything low-level related to graphics first and after display it?
Because you have to have a valid window handle to create the graphics device. You stated previously you didn't want the window to show until things are ready to display.
Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.
You don't forget how to play when you grow old; you grow old when you forget how to play.
Why hide the window and then display it when the correct is to initialize everything low-level related to graphics first and after display it?
Because you have to have a valid window handle to create the graphics device. You stated previously you didn't want the window to show until things are ready to display.
CreateWindow gives me an valid HWND. After this I can use to initialize an Graphics API without calling ShowWindow first.
WM_CREATE looks the standard place to initialize the graphics API as showed earlier but I'm not doing this. So I can call ShowWindow whenever I want - far as I know.
From the user point of view that's make sense. I see. Thank you.If your application takes a while to start up, and you are not displaying a window indicating that things are launching, then most users are going to assume "something is wrong" and try and launch it again.
The correct thing to do here would be to display a splash screen, so the user knows that your application is launching, while at the same time giving you time to prepare your assets for initial scene startup.
Do note that the splash window can be the same window as your final rendering window, for long running things I highly recommend you offload them to background threads, thus ensuring that your window stays responsive.
In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.
