[dx9] device present

Started by
7 comments, last by Nik02 12 years, 8 months ago
Does Present(...) function "presents" content of a last SetRenderTarget()?

I thought it does but not:
clearnotworking.jpg

Last draw is full screen quad, and i got 2 "legal" texture (by iinscpecting their content in PIX) that just cant be red:

OUT.Color.rgb = tex0 * tex1;
OUT.Color.a = 1.0f;

At least it should be white coor as i clear it to that color!
Advertisement
Now, if i setup with dxcpl to maximum debug level i got flickering green i pink colors???
-Where's your BeginScene?

-The flickering pink and green indicate that you're not clearing the primary back buffer. The Clear call will merely clear the current render targets - it is roughly equivalent to drawing a full-screen quad of solid color to the targets.

-Present will swap the device's back buffer with the front buffer in order to display the rendered backbuffer contents on the output device (simplified). It doesn't care about
render target assignments.

Niko Suni

Its there on the begining, just can't see on this screenshot.
I'll try to make minimalistic code to reproduce this and post it here.
Also, you have selected an event before the clear operation, so the display doesn't take into account the clear at all :)

Niko Suni

I have made small example for this.
Looks like i need to use "buffer" created with device?
If you want to draw something to the screen, you set the current render target to the back buffer that was created along with the device (and subsequently draw something to it), and then Present it so that the backbuffer contents are copied (or flipped) to the screen (the act of "presenting" the rendered stuff).

Should you create and render to other render targets, the device's present call doesn't affect said targets. It ONLY present's the device's backbuffer (which may or may not be set as a current render target surface). The device's Present method doesn't care at all what your render target surface happens to be.


FYI:
You can also create your own n-buffered chains like the default swap chain (front buffer+n back buffers), if you do need additional buffered render targets.

That said, it is also completely valid to render to a solitary rt surface. However, in order to use the rendered image therein as a texture, the pipeline has to wait until the previous render task queue is completed (and this will usually cause stalls). The buffering helps overcome this stalling as you have one version of the desired image available even though a newer version is currently in the works by the GPU. Hence, the need for swap chains in the first place.


---


Did you try to select the Clear event (or later) in PIX? In the picture you posted earlier, the event selection cursor is positioned just before the clear event, so the surface display reflects the state immediately before clear. The same goes with draw calls.

Niko Suni

Problem solved, just grabed "old" rt (buffer created with device) after beginScene and "paint" on it last with all my staff before endScene/present.


Did you try to select the Clear event (or later) in PIX?
[/quote]

I just double clicked surface (number/address) so it showed me its content in the right side panel.
In the pic you posted, the surface contents are represented as they are before the clear operation (you have row 1155 selected, the clear event is at 1156). If you would select the row containing the clear event, the image would reflect the cleared state (presumably white surface). And if you select a row after you've drawn some geometry with Draw*Primitive, the image would also show said geometry.

Niko Suni

This topic is closed to new replies.

Advertisement