• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Omroth

GetRenderTargetData - does it block?

13 posts in this topic

Hey guys. I have some code I'm using here to grab the back buffer onto a surface in main memory. My question is: does this block? Ie, will the surface in main memory be ready when this has finished executing? Thanks, Ian D3DDevice->GetBackBuffer( 0, 0, D3DBACKBUFFER_TYPE_MONO, &bBuffer ); // Figure the size we're snagging. D3DSURFACE_DESC desc; bBuffer->GetDesc(&desc); HRESULT hr = D3DDevice->CreateOffscreenPlainSurface(desc.Width,desc.Height,desc.Format,D3DPOOL_SYSTEMMEM,&mBuffer,NULL); D3DDevice->GetRenderTargetData(bBuffer , mBuffer); bBuffer->Release(); if (lastBuffer) { lastBuffer->UnlockRect(); lastBuffer->Release(); } // TODO: Investigate alternatives to D3DLOCK_DONOTWAIT D3DLOCKED_RECT pLockedRect; hr = mBuffer->LockRect(&pLockedRect,NULL, D3DLOCK_DONOTWAIT); lastBuffer = mBuffer;
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Omroth
My question is: does this block? Ie, will the surface in main memory be ready when this has finished executing?
Yes, it'll block - GetRenderTargetData() will finish rendering anything queued up and then copy the contents of the backbuffer to mBuffer.
0

Share this post


Link to post
Share on other sites
Thanks EvilSteve.

I've heard a lot about the inefficiencies of getRenderTargetData requiring DX to finish rendering all of the stuff "queed up". If I'm not worried about screen output, would it make sense to render to a series of buffers, and only call getRenderTargetData on each buffer once it's finished rendering? Would that have an appreciable speed increase?

Thanks,
Ian
0

Share this post


Link to post
Share on other sites
You could double buffer the results, I.e. render to two render targets in turn, which could help, but would introduce a frame of lag.

Why do you need to get the render target data in the first place? There may be a better way to do things.
0

Share this post


Link to post
Share on other sites
I'm able to deal with lag of up to a second really, I just need to be able to get frames from the card to main memory as close to 25 frames a second as possible. I also have no requirement for the graphics card to output anything via VGA at all.

What I'm basically doing is using DirectX/the 3d card to create a video stream, which needs to go via main memory to a separate card for further processing before being output.

Can you think of any techniques I can use to speed this all up?

Cheers,
Ian
0

Share this post


Link to post
Share on other sites
I think you'll probably get the best performance out of using GetRenderTargetData() with a double-buffered system. Anything else will involve locking a default pool resource in non-readonly mode, which is usually a killer for performance.
0

Share this post


Link to post
Share on other sites
DX10 has better support for ths sort of thng (staging buffers, and DO_NOT_WAIT locks), which will likely give you better performance. If using DX10 is an option for you, this is the way to go.
0

Share this post


Link to post
Share on other sites
Thanks again guys.

I'm getting some weird output from this now. The frames I'm getting sent down have a tear in them, a diagonal tear where the top left "corner" seems to be from the previous frame, so I'm assuming that the backbuffer is being written to as GetRenderTargetData is doing the copy.

This goes against what I was expected - do you have any suggestions how I can diagnose this further?

Thanks,
Ian
0

Share this post


Link to post
Share on other sites
Fyi, this is on a Radeon 5850 running Catalyst drivers 2009.0925.1707.28889.

I suppose I should try a driver update as well.
0

Share this post


Link to post
Share on other sites
You can either lock and get a perfect frame, or read it "right the hell now" and you'll get something that isn't quite finished. Not sure what the 3rd option is that you're looking for tbh - this is a logical problem, not a rendering specific thing.

Best advice has been given - use a locking method and double-buffer it to keep the throughput speed up.
0

Share this post


Link to post
Share on other sites
You misunderstand - I /thought/ I was getting the finished frame, as was implied above, by my current method. What extra do I need to do to "lock" it?
0

Share this post


Link to post
Share on other sites
When you use the "do not wait" flag with the lock, you say that you don't care if the rendering is finished or not - just give the data that is in the buffer this instance. Try removing the flag.

I believe that in most GPUs, the surface-to-surface copy is implemented as a simple render operation (though probably bypassing most of the geometry setup needed in "ordinary" rendering). A diagonal tear might simply be an artifact of this process.
0

Share this post


Link to post
Share on other sites
I've tried removing the flags but still get the tearing - am I locking the right thing at the right place? Do I need to "lock" the backbuffer as well?

Thanks for all the help guys,
Ian
0

Share this post


Link to post
Share on other sites
Guys I googled this
Quote:

"
When I try to play Nocturne it gives me the error message:

Unable to Lock Front Buffer

File: wddvmem.cpp
Line: 838

I'm running Vista, but I've changed the GameTap compatibility properties to XP. I've tried everything that works with other games (i.e. BlloodRayne) such as Run as Administrator, Run in 256 Color, Run in 600x480 etc. If anyone has any other suggestions I'm game.
"


If front buffer is lockable , then, after call to Present(), Front buffer is lockable with delay of 0. If present() blocks of course. You should be able to access it for reading.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0