0
\$\begingroup\$

So far I've put together a bare minimum of a DirectX 11 application. All it does is clear the window to a random shade of red.

const FLOAT clearColor[4] = { rand() / (float) RAND_MAX, 0.0F, 0.0F, 1.0F };

context->ClearRenderTargetView(renderTargetView.Get(), clearColor);
context->ClearDepthStencilView(depthStencilView.Get(), D3D11_CLEAR_DEPTH | D3D11_CLEAR_STENCIL, 1.0F, 0.0F);

swapChain->Present(0, 0);

What I get however is a constant flickering (sort of like z-fighting, but apparently not).

Flickering Image on DX11 clear

If I enter fullscreen by pressing Alt + Enter, and then leave, this problem is solved, it no longer flickers in any way. What settings does alt + enter end up changing?

What could cause this? I don't want to continue and find out this becomes an issue later. I'll update the question with code on request.

Secondary question: In fullscreen mode, there's a lot of flickering in horizontal bars, yet images only capture a single colour at once. Is this normal, some illusion, or also avoidable?

Update: When using "swapChain->Present(1, 0);" the original flickering still occurs (Seemingly less severely), but no longer in fullscreen mode.

\$\endgroup\$
4
  • \$\begingroup\$ Use a graphics debugger and check the framebuffer content after each rendered frame. PIX is good at DirectX last I checked. See if there is a difference in produced frame vs frame on screen. \$\endgroup\$ – Andreas Aug 5 '16 at 17:23
  • \$\begingroup\$ I'll give that a go, thanks. It'll have to be in the morning though, it's late. I did quickly try VS graphics debugger and all frames are captured as solid. I might have to look more in to states of the objects I have and how they change. \$\endgroup\$ – Dan Wattle Aug 5 '16 at 17:45
  • \$\begingroup\$ Then it is probably an error in how the framebuffer is finally put on display. Is your framebuffer setup as single buffer or double buffer? (Sorry for the OpenGL terminology) \$\endgroup\$ – Andreas Aug 6 '16 at 7:51
  • \$\begingroup\$ As Le Comte pointed out this is not z-fighting based on what you say you do. You would have to draw primitives with depth test turned on for that to occur which as far as I know "clear" can not do. Edit the question appropriately. \$\endgroup\$ – Andreas Aug 6 '16 at 7:54
1
\$\begingroup\$

It turns out that it's been an unknown local issue. After resuming the project later with no changes, other than restarting and Windows updates, I'm not having this issue anymore. The Windows 10 Anniversary Update (intrusively) did revert a lot of settings to default however and this may have impacted it.

\$\endgroup\$
0
\$\begingroup\$

This isn't Z-fighting, it's screen-tearing.

Z-fighting, by definition, cannot occur with your code:

...a phenomenon in 3D rendering that occurs when two or more primitives have similar or identical values in the z-buffer.

You don't even have any primitives and your Z-buffer is just set to a single constant value, so Z-fighting is impossible. Both your main problem, and that observed in your secondary question, are simple screen-tearing.

Pressing Alt-Enter to go fullscreen resolves it because you most likely have not called IDXGIFactory::MakeWindowAssociation to disable automatic DXGI handling of this transition. So DXGI itself is stepping in and changing to a valid fullscreen mode with vsync forced on, which will prevent screen-tearing.

Calling Present(1,0) yourself doesn't fully resolve it because you most likely have your swapchain initialized to an invalid refresh rate. Typically this happens when you specify a refresh rate of 60Hz but your monitor's real refresh rate is actually slightly different (maybe 59.95 or something similar). The way to resolve this is to enumerate your display modes properly using IDXGIOutput::GetDisplayModeList and use one of those enumerated modes for the DXGI_MODE_DESC member of your DXGI_SWAP_CHAIN_DESC. Pay particular attention to the Numerator and Denominator members of DXGI_MODE_DESC::RefreshRate to understand the difference: this happens more commonly than you might think.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ I thought about this, but the pattern I was receiving made it not look like screen tearing, it's not a single split like on the wiki page, it's more arbitrary. I also thought there was no primitives, but it looks like D3D is clearing the screen by producing 2 triangles filling the screen? Anyhow I'll give display modes a shot. Thanks. \$\endgroup\$ – Dan Wattle Aug 6 '16 at 4:04
  • 1
    \$\begingroup\$ I didn´t know screen tearing could present itself as non-horizontal, asymmetric artifacts. Are you really sure this is screen tearing? My first thought was this was due to single buffering, ie only having a front buffer. Your explanation as to why it works in fullscreen holds for that theory holds true I think. \$\endgroup\$ – Andreas Aug 6 '16 at 7:49
  • \$\begingroup\$ Appologies for fragmented comment. Your fullscreen reasoning holds true for that theory. \$\endgroup\$ – Andreas Aug 6 '16 at 7:56
  • \$\begingroup\$ @Andreas and Le - So here's the fun part. The issue has resolved itself. I've changed none of the code nor any system settings. I've restarted my computer a few times due to the W10 Anniversary Update, but nothing else. I've even tried replicating the original issue, but can't. Bit of a pain as the problem will be unknown now, but ah well. Thanks. \$\endgroup\$ – Dan Wattle Aug 6 '16 at 12:30
  • \$\begingroup\$ @DanWattle - you can post this as your own answer & accept it yourself. \$\endgroup\$ – Maximus Minimus Aug 6 '16 at 16:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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