Jump to content

  • Log In with Google      Sign In   
  • Create Account

knatterton

Member Since 12 Jul 2012
Offline Last Active Jun 24 2014 01:44 AM

Topics I've Started

Fullscreen problem

29 January 2014 - 02:02 AM

Hi,

 

We have encountered a strange problem with our DirectX 9 application when it's running on Windows 8.1 x64. The application is working correctly in windowed mode, but when we go to fullscreen mode the GPU stops working completely (according to GPU-Z). It only renders the first image and then nothing. The application is still running - you can hear sounds and click on GUI items, but the image on the screen is completely frozen. The only thing that seems to help is to alt-tab out of the application and then back in. After that the GPU seems to wake up to render images again. Going to windowed mode and back to fullscreen mode freezes the image again. Alt-tabbing to the desktop and then back to the application is the only thing that seems to work.

 

Any ideas what could be causing this kind of thing? We have only encountered this problem on Windows 8.


Terrain tessellation

18 December 2012 - 02:52 PM

Hi, I'm in the process of implementing tessellated terrain for our engine. Everything works sort of okay already, except there's no frustum culling and the LOD could be improved. As I was looking for ways to improve the tessellation I found a paper called "DirectX 11 Terrain Tessellation" by Iain Cantlay. It has lots of interesting ideas about tessellation, but unfortunately there doesn't seem to be any source code available of the implementation. Does anyone know if the source code can be downloaded somewhere?

In the paper frustum culling has been implemented by dividing the terrain into multiple vertex buffers, which are then individually culled and then rendered using instancing. Wouldn't it also be possible to use the hull shader to cull individual patches? Would multiple vertex buffers be the better choice of these two approaches since our application is GPU bound and is likely to remain that way?

PIX error message

14 September 2012 - 03:54 AM

Hey,

We've been using PIX successfully in the past, while we were still using DXUT. However, now that we got rid of DXUT, PIX is giving the following error message whenever trying to view draw call results:

A call that previously succeeded failed during playback:
EID: 128
Call: IDXGIFactory::CreateSwapChain()
HRESULT: DXGI_ERROR_INVALID_CALL

My operating system is Windows 7 x64, PIX is 64-bit and the debugged application is 32-bit. The application is working fine outside of PIX, and there are no errors or warnings that are related to Direct3D. I tried looking through the PIX documentation for information about this error, but most of the things there seemed to be about Direct3D 9. So... What could possibly make the CreateSwapChain() call fail in PIX, when it's working fine otherwise?

Problems going fullscreen

07 September 2012 - 12:09 PM

Hey,

My application starts up successfully in windowed mode and now I'm trying to switch to fullscreen mode without any changes in display mode. In other words, I want to keep the desktop resolution and refresh rate. I expected this to be a fairly easy thing to accomplish, but I've run into a problem that I can't seem to solve. I've set up my application so that the Enter key switches between windowed and fullscreen modes. I've also disabled Alt-Enter from doing the same, but I'm fairly certain that has nothing to do with this particular problem. This is what happens after I press Enter:

1. Key press is correctly detected.
2. DXGISwapChain::SetFullscreenState(true, nullptr) is called.
3. Immediately after SetFullscreenState() the application goes fullscreen and a WM_SIZE message is received.

This is when the problems start. The application does go to fullscreen mode successfully, but the display mode is also changed. Also the width and height received with the WM_SIZE message seem to be incorrect. When running the application on my TV the display mode changes from 1920x1080@60Hz to 1920x1080i@60Hz and the size received with WM_SIZE is 1768x992. When running the application on my monitor the display mode changes from 1920x1200@60Hz to 1600x1200@60Hz and WM_SIZE delivers 1008x730.

4. After getting the WM_SIZE message, IDXGISwapChain::ResizeBuffers() is called with the new width and height values, but it doesn't matter really, because something has already gone wrong before this step.

This behavior seems strange to me, because I've created the swap chain without the DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH flag. I also never call IDXGISwapChain::ResizeTarget(). So what's changing the display mode anyway? I thought that calling SetFullscreenState() was supposed to keep the current desktop resolution, but I must have misunderstood something. Any obvious things I might have missed? Could my dual monitor setup have something to do with this? I can also post some code samples if that would be helpful.

Any help would be appreciated!

PARTNERS