Jump to content
  • Advertisement
Sign in to follow this  
howie_007

post process question

This topic is 2542 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

From the examples I have found, post process seems to be handled by rendering the final scene to a texture surface and then rendering a full screen quad to the back buffer with that texture. This is how the pixel shaders are activated via a "DrawPrimitives" call with that full screen quad.

My question is, is this still how it's still done today? Seems like a wonky process. Is there a way to kick off the pixel shaders by telling DirectX to render this texture to the back buffer?

Perhaps the pixel shader can be activated by a "Draw" call from a D3DXSPRITE? The D3DXSPRITE can be asked to render the texture to the back buffer. Would that work?

Share this post


Link to post
Share on other sites
Advertisement
If you poke at how D3DXSPRITE works behind the scenes (using PIX) you'll find that exactly all it does is copy vertexes to a vertex buffer and draw them using DrawPrimitive. Might as well do it yourself.

Share this post


Link to post
Share on other sites
Yup, that is pretty much how it works. You are just trying to get the pixel shader to be invoked for each pixel, which amounts to having a full screen quad rendered via a draw primitive command.

In most cases, the additional render target is needed anyways - for example, when using MSAA you would need a separate render target to be rendered into, then resolve the resource to somewhere else (the back buffer usually...). It may not seem perfect, but it allows you to have a uniform way of interacting with the pipeline instead of having different semantic approaches.

Share this post


Link to post
Share on other sites

If you poke at how D3DXSPRITE works behind the scenes (using PIX) you'll find that exactly all it does is copy vertexes to a vertex buffer and draw them using DrawPrimitive. Might as well do it yourself.


If it's all the same thing, I'll just go the D3DXSPRITE route since it's a much more simplified approach.

Share this post


Link to post
Share on other sites

[quote name='mhagain' timestamp='1324749415' post='4897113']
If you poke at how D3DXSPRITE works behind the scenes (using PIX) you'll find that exactly all it does is copy vertexes to a vertex buffer and draw them using DrawPrimitive. Might as well do it yourself.


If it's all the same thing, I'll just go the D3DXSPRITE route since it's a much more simplified approach.
[/quote]

Simplified but at a cost. It will create a single biggish dynamic vertex buffer and continually append to it, then discard when full (and likewise with an index buffer - the classic dynamic buffer usage pattern in other words) whereas in reality all that you actually need is a single vertex buffer that doesn't need to be dynamic. That will generate some overhead in terms of both performance and resource usage - might or might not be measurable, depending on what you're doing elsewhere. You're also restricted in terms of the data that can be passed into the shaders; it's going to be position, colour and texcoords and nothing else. I've found use cases where it's handy to be able to pass in e.g. a second set of texcoords.

Personally I'd just use a static vertex buffer and DrawPrimitive (DrawPrimitiveUP may even be OK for this) to give myself headroom for future expansion; it's just 3 function calls (SetStreamSource, SetVertexDeclaration and DrawPrimitive) which is really not worth the tradeoff of simplifying further at the cost of less flexibility.

Share this post


Link to post
Share on other sites

Simplified but at a cost. It will create a single biggish dynamic vertex buffer and continually append to it, then discard when full...

Why would it append to it? I assumed it would create the vertex buffer quad, use it and release it. I use D3DXSPRITE to render my 2D menus.

Share this post


Link to post
Share on other sites

[quote name='mhagain' timestamp='1324754996' post='4897134']
Simplified but at a cost. It will create a single biggish dynamic vertex buffer and continually append to it, then discard when full...

Why would it append to it? I assumed it would create the vertex buffer quad, use it and release it. I use D3DXSPRITE to render my 2D menus.
[/quote]

Create/use/release every frame will kill performance. I'd encourage you to use PIX to look at what's happening with D3DXSPRITE (and confirm that it's appending to a dynamic buffer); having an understanding of what helper interfaces do behind the scenes will stand to your good longer term too. It's just the classic dynamic vertex buffer pattern that is documented in the DirectX SDK but in this case the buffer doesn't need to be dynamic.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!