Jump to content

  • Log In with Google      Sign In   
  • Create Account

RythBlade

Member Since 01 Jan 2012
Offline Last Active Aug 13 2013 04:44 AM

Posts I've Made

In Topic: Render To Texture only color, no texture

16 October 2012 - 09:44 AM

The difference between those two flags is that:

DXGI_FORMAT_D32_FLOAT specifies a depth buffer where the depth is stored as a 32-bit floating point value.

DXGI_FORMAT_D24_UNORM_S8_UINT specifies that the depth buffer is stored as a 24-bit floating point value. The remaining 8 bits (the _S8_UINT section) specifies the stencil test value is stored as an 8-bit unsigned integer.
You'll need to have another look through your set up of the depth-stencil test and how you create your graphics device and back buffer to ensure you've got depth testing AND stencil testing enabled along with the back face culling.

These are some good tutorials with excellent explanation of the parameters etc that should help you get to grips with setting this stuff up:
http://www.directxtutorial.com/Tutorial11/tutorials.aspx
This one is also a more complete example but a bit harder to follow.
http://www.rastertek.com/tutdx11.html

Hope this helps!

In Topic: Direct3D11 crashing display driver

16 October 2012 - 09:32 AM

Recreating your devices from scratch will take a considerable amount of time as the majority of DirectX objects rely on the device and context so would need to be recreated also.

I can think of a few possibilities - for your problem - like MJP says, when a GPU task takes too long your graphics driver will time out. For instance if you attempted to render an obsene amount of triangles and do heavy shader calculations on them, all in one go - your grpahics driver will probably die. I had this problem while writing a DirectCompute shader that sometimes took a very long time and kept killing my drivers.

Also - the device object has some quirks when its windowed. For example in a multi-screen situation, draggin the window from one screen to the other will destroy your current graphics device object, as we've changed which physical device we want to use.

The DXUT framework is really good at handling this sort of thing for you with some handy event handler stub functions.

This may also happen when you minimise the window (I can't remember if I've actually ever tried this.....).

Also I believe if your running it in full-screen and you minimise, this can cause problems as well similar to those above. If you're in full-screen mode, use the alt+enter shortcut to switch back to a windowed mode. Then you should be able to get to visual studio without minimising the window - you're just moving focus to another window - which in my experience has always been fine.

You could also try placing some timers around you draw calls that output to the debug window. Compare the times in situations where it works and doesn't work to see if its a long running GPU task that kills the device - in this instance you'd probably see a long running time or a start time without a finish time immediatly before the crash.

Hope this has been helpful!!

In Topic: [DX11] HLSL 5 setting SamplerState from within the shader isn't working

20 April 2012 - 04:05 AM

For all those that are interested - just found this post which discusses a nice way to deal with this situation, which is what I'm now going to do. The developer automatically sets up a set of SamplerState objects in their engine and set them in the shaders by default. The shaders have a common include containing the register references for all of these so that all shaders have access to set of samplers etc automatically.

[Edit:] Though I'd give a quick update - this method works fantastically - all my shaders now have immediate access to any samplers they might need and its simplified my some parts of my engine code a lot! Works perfectly.

In Topic: [DX11] HLSL 5 setting SamplerState from within the shader isn't working

20 April 2012 - 04:02 AM

No I'm not.....goddamn it! I was hoping for a quick win.....Ok. Yeah it looks like you're right, just stumbled onto this post after reading your reply. It seems my google-fu is still not as strong as I'd hoped.
Thanks very much for the help!

In Topic: DirectX 11 Jerky rendering

04 April 2012 - 07:50 AM

Ok I think I've tracked down more of my problem - I had quite a lot of debug messages printing. As soon as I removed them the stammering reduced further. So I've compiled it under release mode and now its barely noticeable.
I'm still unsure as to why it suddenly became an issue for me though considering in my past experience its not been much of a problem....

PARTNERS