Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Member Since 08 May 2012
Offline Last Active Yesterday, 04:02 PM

Posts I've Made

In Topic: Shadow Mapping Depth Buffer

19 November 2014 - 06:17 PM

I solved my problem. My projected texture coordinates was incorrect. The correct is:

vProjTexCoord.y = (vProjTexCoord.y * -0.5f) + 0.5f;

I was checking the Lighting Volume in HDC coordinates. Eg.:

if ( vLightPos.x >= -1.0f || ...etc. )

Also, I wasn't creating a Sampler. Since I'm not using the Effects Framework, had to set it manually.


Thank you.

In Topic: Win32 Window Creation

29 October 2014 - 02:16 PM


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.

In Topic: Win32 Window Creation

29 October 2014 - 01:04 PM

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.

In Topic: Win32 Window Creation

29 October 2014 - 12:48 PM


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.

In Topic: Win32 Window Creation

29 October 2014 - 09:47 AM

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.