Question

So, I am using Visual Studio 2012 with the “onboard” Windows SDK 8, writing Direct3D11 applications and i have a huge problem. I have a class which handles all the initialization, setup and draw calls on top off D3D11. I instantiate the application class which holds an instance of the D3D11 driver class properly with all the data it needs to know.

The D3D11 driver class constructor takes the application’s primary window handle and uses it to hook D3D into the application’s primary window. It constructs itself properly and returns out where it calls app->run() which drives the main loop.

In the main loop, that driver is called to simply test draw a blank reddish screen. Observing the debug information, the render target in question is operational, created to bind the backbuffer from the swap chain to the pipeline.

renderTargetView IS NOT NULL. HRESULT is validated to be S_OK.

If I try to call the Draw function within the D3D11 driver class constructor, it works. It doesn’t get deallocated inbetween calls.

It’s like the constructor of the Application class doesn’t finish before the run() function, if I try to continue without exiting for a few “frames” forward, the reddish tint of the cleared render target shows. Can someone enlighten me, please? I’m at the end of my wits.

IT’S NOT NULL. HRESULT is validated to be S_OK. There are reports this is fixed in Windows 8, while the Win7 SDK still suffers. Google doesn’t yield anything useful, most people forget to create the render target view (stays NULL) or intellisense-miss OMSetRenderTargets for OMGetRenderTargets.

Answer 1

Unhandled exceptions are almost exclusively dropped when you dereference a null pointer. The ClearRenderTargetView() is an instance method of a validly initialized (immediate) context, or

ID3D11DeviceContext::ClearRenderTargetView(...)

If you didn’t make the trivial mistakes of not initializing the render target view or calling OMGetRenderTargets(...) instead of OMSetRenderTargets(...), I am absolutely certain that your context is null. Per your statement, you explicitly deny making these mistakes.

Use assert to verify my claim, that your context is indeed NULL. Since it works in your driver constructor and doesn’t later when it is used as a member of your application class, you’re probably not supplying a proper copy assignment operator in your driver class, that’s why it drops an unhandled exception box, it initializes the context and then doesn’t persist due to a missed reference copy. While the object is being initialized, it is partially valid, that’s why it works that one time.

This is just a hypothesis, I’m pretty certain, but due to the lack of code on your part, I can only use my imagination and logic. Report back if you need further assistance.