Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm attempting to write a small screen capture utility that writes captured video to disk.

First, I get the front buffer surface. I've written a shader that takes this surface and through render to texture, converts it to a YUY2 format frame. The format change is required so that I can pass the frames off to an encoder.

I'm using DirectX 9 to acquire the frontbuffer. There are a couple of ways I know of to get at the front buffer:

GetRenderTargetData()

GetFrontBufferData()

The MSDN page on both of these API calls state that the data is copied from device memory to system memory. I'd like to copy the front buffer surface directly to another graphics memory surface, as I have other manipulations to perform on the acquired surface before returning it to system memory.

I'm creating a D3DUSAGE_DYNAMIC texture (gfx mem texture) and calling GetFrontBufferData() to write the front buffer to my textures surface0. Is this valid? Will the operation remain in gfx memory, or will it need to move to system memory and then back to graphics memory? If this is the case, is what I'm trying to achieve possible?

EDIT I've been acquiring the front buffer as below, simply because its a convenient way to get a surface populated:

hr = Dx9Mgr::Ref().D3DDev()->GetFrontBufferData( 0, m_spCaptureSurface );

OTOH, GetBackBuffer() allocates a new surface (I want to reuse one over and over), so I just went with GetFrontBufferData().

GetRenderTargetData() requires that the destination surface be created in system memory rather than in gfx memory (e.g. uses D3DPOOL_SYSTEMMEM ), so I ruled this out. Maybe I should reconsider?

share|improve this question
    
This doesn't appear to be particularly game related other than using D3D, and since you're asking about making a screenshot program I think you will find better responses on StackOverflow. –  Josh Petrie Jan 3 at 15:48
add comment

closed as off-topic by Josh Petrie Jan 3 at 15:48

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Programming questions that aren't specific to game development are off-topic here, but can be asked on Stack Overflow. A good rule of thumb is to ask yourself "would a professional game developer give me a better/different/more specific answer to this question than other programmers?"" – Josh Petrie
If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer

GetFrontBufferData is documented as being incredibly slow and unsuitable for use in any performance-critical path. In general terms the front buffer is something that belongs to your display subsystem and your program normally does not have access to it.

It's highly likely that there is a much better way of achieving the result you want without needing to access the front buffer at all. From the sound of it, you're talking about something that can be solved by a completely standard render-to-texture setup, but you'd need to give much more info on what it is you're trying to do before anyone could comment further.

share|improve this answer
    
I've updated my original question to include more information about what I'm doing. –  lapin Jun 12 '12 at 13:10
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.