Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 25 Nov 2009
Offline Last Active Apr 22 2013 07:23 AM

Topics I've Started

DX10: Render back buffer to texture

14 March 2013 - 09:20 AM

I want to render the back buffer to another texture (performing scaling and other operations). If the back buffer wasn't created with the D3D10_BIND_SHADER_RESOURCE flag, is my only option then to create an intermediate texture (where I *do* set D3D10_BIND_SHADER_RESOURCE), use CopyResource() to copy the back buffer to the intermediate texture, and then bind the intermediate texture for rendering to my render target texture?

Deferred contexts and inheriting state from the immediate context

25 October 2012 - 08:39 AM

I took my first stab at using deferred contexts in DirectX 11 the other day. My use-case for deferred contexts is probably somewhat different from the common scenario though; I'm interested in rendering a bunch of things on a deferred context, have them executed on the immediate context and then have the API reset the immediate context to what it was before I executed my commands (i.e. basically restoring the render state).

To test this, I created my deferred context using CreateDeferredContext() and then rendered a simple triangle strip with it.

Early on in my test application, I call OMSetRenderTargets() on the immediate context in order to render to the swap chain's back buffer. Now, after having read the documentation on MSDN about deferred contexts, I assumed that calling ExecuteCommandList() on the immediate context would execute all of the deferred commands as "an extension" to the commands that had already been executed on the immediate context, i.e. the triangle strip I rendered in the deferred context would be rendered to the swap chain's back buffer when I executed the generated command list on the immediate context.

That didn't seem to be the case, however. Instead, I had to manually pull out the immediate context's render target view (using OMGetRenderTargets()) and then set it on the deferred context with OMSetRenderTargets().

Am I doing something wrong or is that the way deferred contexts work?

State blocks in DX10

24 February 2012 - 11:10 AM

I've used state blocks (http://msdn.microsoft.com/en-us/library/windows/desktop/bb206121%28v=vs.85%29.aspx) with Direct3D 9 in the past to save off the current render state, make some state changes, render some primitives, and then reset the render state to what it was previously.

How do I do something similar in Direct3D 10/11? I basically want to take the current render state (e.g. shaders, input layout) and save them off, change the state to whatever I need in order to render something else, and then set the state back to what it was before I rendered.

Multiple Direct3D 9 devices and Alt-tabbing

23 January 2012 - 09:05 AM

I have an application that creates a Direct3D 9 device in fullscreen mode and then starts presenting. At a later point, after having created the first device, I temporarily create a new Direct3D device in windowed mode (on the same thread but for a different window). I destroy this device immediately again, but somehow I'm then no longer able to Alt-tab out of the fullscreen application anymore. The application just stays on top rather than dropping to the background although it looks like the application is no longer in focus.

If I create my temporary device as D3DDEVTYPE_NULLREF, I'm suddenly able to Alt-tab out. Does anybody have an idea why that is, and if so, how I can create a second temporary device without messing up the existing device?

Performance: Readback of back buffer via shared resources

26 October 2011 - 09:29 AM

I need to copy the back buffer of a game to a system memory surface. As we all know, that's a horribly bad situation for performance since it requires syncing the CPU and GPU. Due to certain restrictions, however, I cannot use GetRenderTarget() in the application itself to read the back buffer. Instead, I do the following:

* Create a shared render target surface (DirectX9Ex) in video memory in a different application.
* In the context of the game, blt the contents of the back buffer into the shared resource.
* Call GetRenderTarget() data on the shared surface in the other application to read the contents into system memory.

This works fine, but it made me curious about the performance of the readback operation in general. Since the actual readback happens on a different surface than the game's back buffer, does this mean the game will be able to continue rendering while I'm reading back from the shared surface or will the CPU<->GPU sync affect everything?