Sign in to follow this  

DX11 Is it time to upgrade to Dx11?

This topic is 1057 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

My hobby engine/game has been in development for some time now (5+ years it must be) and it's starting to come together nicely. I have had a rudimentary material system in place for a while but it's time to do it properly.

I'm using Directx 9c and I'm wondering whether I should spend some time upgrading to DX11 first. If I write a flexible material/shader system, am I going to have more of a headache upgrading it at a later stage?

I haven't really looked in too much detail at the differences between the APIs but they seem to be fairly extensive.

I guess I'll pre-empt the question of what hardware I'm targeting with, the 'latest'. I would like to think that my engine/game(s) would run on the latest consoles - whether that happens is, of course, a different debate.

Share this post


Link to post
Share on other sites
Might want to hold off a bit if it isn't a major issue yet; DX12 will bring another major API shift and with Win10 going 'free' for anyone with Win7 or Win8 it could well get a lot of traction.

Share this post


Link to post
Share on other sites

If you do make a new system in 9, but think you may want to upgrade at some point, then base your system around cbuffers. They were the big change in 10/11, and they'll be sticking around for 12 too.
I wrote a post years ago on how I emulate cbuffer support on 9:
http://www.gamedev.net/topic/618167-emulating-cbuffers/

Thanks, I'll take a look. The more I can do at this stage to align it to later versions the better

Share this post


Link to post
Share on other sites


Might want to hold off a bit if it isn't a major issue yet; DX12 will bring another major API shift and with Win10 going 'free' for anyone with Win7 or Win8 it could well get a lot of traction.

 

hmmm...I don't know. Seems like a real nice dangling carrot that precursors an OS subscription based pay system. Not the cool Epic deal you all know and love but more of a 'able to pull the plug' when you don't pay relationship. Personally, I think it's a trap and your OS will actually cost more in the long run. 

 

I'd hold off as well but for different reasons. What I'm waiting for is glNext because I feel the giant is about to pull another fast one.

 

 

edit: V V V 

Sure, sure....that's cool. Hardly paranoid, as I don't care what happens with the WindowsOS.

We'll just have to wait and see in a year and a half plus or there about.

I hope you're right and Win10 stays free after the first year, but I doubt it. 

I'll also spoil my name some more and say DX12 will be Win10/xBox_n only. 

Seeing the DX12 pluging away in the openGL boards, seems fair to make mention of glNext in here.

 

Whatever the case, I apologize to the original poster because of my 'raving paranoia'. (thank you for the smart words phantom) For me, DX11 was actually a decent choice on a PC running Vista / Win7 because you could drop back to a lower hardware feature set (DX9) using the DX11 interface which allowed it to run on older hardware. I don't have high hopes for DX12 following this pattern because, you'll still need DX12 hardware. but hey, hopefully I'm wrong. 

Edited by Goliath Forge

Share this post


Link to post
Share on other sites

hmmm...I don't know. Seems like a real nice dangling carrot that precursors an OS subscription based pay system. Not the cool Epic deal you all know and love but more of a 'able to pull the plug' when you don't pay relationship. Personally, I think it's a trap and your OS will actually cost more in the long run.


Wait... wut?
How can a free OS cost you more in the long run?
You are going to have to explain this because right now it looks like raving paranoia...
 

I'd hold off as well but for different reasons. What I'm waiting for is glNext because I feel the giant is about to pull another fast one.


Your paranoia aside if anyone is going to drop the ball this time it'll be the ARB as they have a history of ball dropping which is frankly excellent. Edited by phantom

Share this post


Link to post
Share on other sites
I find this both a good and difficult question. To illustrate, I'm in a similar position, having the dx11 book from frank luna lying around for half a year. Personally I can do what I want with dx9 for now, making simple games, improving my engine. On the other hand, there are features that will be "easier" with dx11. Everything that you learn new, can be a potential waste if you have to learn it all over again.

My advice would be to play around with dx11, learn the basics in a separate/ standalone application, and then decide. That's probably what I'm gonna try myself.

Share this post


Link to post
Share on other sites

I'll also spoil my name some more and say DX12 will be Win10/xBox_n only.

 

That's already confirmed, so you're right about that.

 

For me, DX11 was actually a decent choice on a PC running Vista / Win7 because you could drop back to a lower hardware feature set (DX9) using the DX11 interface. I don't have high hopes for DX12 following this pattern. but hey, hopefully I'm wrong. 

 

The current Windows 10 technical preview includes a build of D3D 12 that exposes feature levels down to 9.1, just the same as D3D 11 did, so you're wrong about that.

 

You see, there's a difference here between making statements based on actual verifiable sources on one hand, versus doomsaying predictions based on personal prejudices on the other.  If you do the latter you should realistically expect to be called out on it.

Share this post


Link to post
Share on other sites

Whatever the case, I apologize to the original poster because of my 'raving paranoia'. (thank you for the smart words phantom)


If you are going to make up bullshit then I'm going to call you on the aforementioned bullshit, simple as.
If in response to this you wish to resort to childish down voting of reasonable posts then carry on, your ire at being called out amuses me and underscores the kind of person you apparently are. smile.png Edited by phantom

Share this post


Link to post
Share on other sites
No apology necessary, but do play nice - it didn't feel like GF was trying to state facts, it felt like an opinion to me.

Either way, all's well that ends well - I'm holding off for a bit but writing it with future changes in mind - it shouldn't be too difficult.

Share this post


Link to post
Share on other sites

I haven't ever developed directly in dx9, but have previously developed in xna 4.

 

Currently I am developing in dx11 and find the whole deferred rendering and cbuffer concept simple and logical, I wouldn't ever want to go back to the old ways.

 

DirectX 11 and above are the future but on that note your dx9 apps will still continue to work for quite some time.

 

Good luck in your decision! 

Share this post


Link to post
Share on other sites

Back on-topic, and regarding differences between the two, there are a few areas where (even if you're currently exclusively using vertex buffers and shaders) you may find it difficult.

 

If you're extensively using D3DX you'll either have to rewrite or find replacement libraries.

 

If you're using the Effects framework you're strongly advised to switch over to the base API.  Effects 11 was distributed (as source only) with the old DirectX SDKs, but it's far from being the most efficient option.

 

DXGI is hugely different from the old D3D9 way of doing things.  You've basically two options here: let DXGI handle everything automatically but at the cost of losing some flexibility (which may be important to you), or disable the automatic handling and have to deal with all of the low-level nitty-gritty of window management yourself.  Neither is perfect but that's just the way it is.

 

States are also very different and you'll be creating state objects up-front rather than issuing Set*State calls as required and based on what you're drawing and how you want to draw it.  This needs a lot more advance planning than D3D9 did, especially if you've built up a reasonably flexible renderer where you don't necessarily know everything up-front.

 

If D3D9 is currently doing everything you need, if you're not currently hitting any of it's limitations, and if you've no compelling reason to use any of the new API features, I'd suggest that you stay with 9 and invest your time and effort into improving your D3D9 renderer.  Otherwise you could find yourself this time next year with no progress made aside from a port to a new API.

 

If you do decide to make the jump then I'd suggest that you begin by staying with 9 initially but rewrite where necessary to tackle the areas where you're going to hit trouble.  So remove your usage of D3DX, move away from Effects to the base API in 9 (use D3DCompile for compiling shaders), move away from Set*State calls to StateBlocks, and create StateBlocks that encapsulate the same groups of states that D3D11 state objects do.  That way it'll go a lot easier on you when you come to do the port for real.

Share this post


Link to post
Share on other sites

Might want to hold off a bit if it isn't a major issue yet; DX12 will bring another major API shift and with Win10 going 'free' for anyone with Win7 or Win8 it could well get a lot of traction.

 

For very experienced developers, hobby or otherwise, I think this advice rings true. But I'm no so sure for less-experienced devs, or those who don't care about ultimate performance at the cost of dealing with the much-more explicit model of D3D12. I think ultimately there will end up being an "easy mode" API that puts the training wheels back on Direct3D 12 for those who want a simpler model and don't need unfettered performance, but as far as I've heard, no such thing is coming immediately, and Direct3D11.x will sort of serve that role in the meantime.

 

And as Hodgeman suggests, the best thing to probably do now is to use D3D11 in a way that prefers the constructs and patterns that'll stick around in the new world order.

 

 

That said, there's probably a balance to be struck, too -- We all know the hoops one must jump through in old-world Direct3D to make a scene look good in only a few thousand draw calls (and etc.), and I think there's a case yet to be made whether dealing with the newly-explicit threading models and synchronization issues (+more)of D3D12 are a greater or lesser headache than that in the long run. But at least for the immediate term D3D11 (and 9, even, if you want to target Asia) makes a lot of sense until everyone is on Windows 10, and that will give more-experienced, early-adopters of Direct3D 12 time to figure out what best-practices are for the less-experienced to follow.

Share this post


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

  • Similar Content

    • By mister345
      Hi, can somebody please tell me in clear simple steps how to debug and step through an hlsl shader file?
      I already did Debug > Start Graphics Debugging > then captured some frames from Visual Studio and
      double clicked on the frame to open it, but no idea where to go from there.
       
      I've been searching for hours and there's no information on this, not even on the Microsoft Website!
      They say "open the  Graphics Pixel History window" but there is no such window!
      Then they say, in the "Pipeline Stages choose Start Debugging"  but the Start Debugging option is nowhere to be found in the whole interface.
      Also, how do I even open the hlsl file that I want to set a break point in from inside the Graphics Debugger?
       
      All I want to do is set a break point in a specific hlsl file, step thru it, and see the data, but this is so unbelievably complicated
      and Microsoft's instructions are horrible! Somebody please, please help.
       
       
       

    • By mister345
      I finally ported Rastertek's tutorial # 42 on soft shadows and blur shading. This tutorial has a ton of really useful effects and there's no working version anywhere online.
      Unfortunately it just draws a black screen. Not sure what's causing it. I'm guessing the camera or ortho matrix transforms are wrong, light directions, or maybe texture resources not being properly initialized.  I didnt change any of the variables though, only upgraded all types and functions DirectX3DVector3 to XMFLOAT3, and used DirectXTK for texture loading. If anyone is willing to take a look at what might be causing the black screen, maybe something pops out to you, let me know, thanks.
      https://github.com/mister51213/DX11Port_SoftShadows
       
      Also, for reference, here's tutorial #40 which has normal shadows but no blur, which I also ported, and it works perfectly.
      https://github.com/mister51213/DX11Port_ShadowMapping
       
    • By xhcao
      Is Direct3D 11 an api function like glMemoryBarrier in OpenGL? For example, if binds a texture to compute shader, compute shader writes some values to texture, then dispatchCompute, after that, read texture content to CPU side. I know, In OpenGL, we could call glMemoryBarrier before reading to assure that texture all content has been updated by compute shader.
      How to handle incoherent memory access in Direct3D 11? Thank you.
    • By _Engine_
      Atum engine is a newcomer in a row of game engines. Most game engines focus on render
      techniques in features list. The main task of Atum is to deliver the best toolset; that’s why,
      as I hope, Atum will be a good light weighted alternative to Unity for indie games. Atum already
      has fully workable editor that has an ability to play test edited scene. All system code has
      simple ideas behind them and focuses on easy to use functionality. That’s why code is minimized
      as much as possible.
      Currently the engine consists from:
      - Scene Editor with ability to play test edited scene;
      - Powerful system for binding properties into the editor;
      - Render system based on DX11 but created as multi API; so, adding support of another GAPI
        is planned;
      - Controls system based on aliases;
      - Font system based on stb_truetype.h;
      - Support of PhysX 3.0, there are samples in repo that use physics;
      - Network code which allows to create server/clinet; there is some code in repo which allows
        to create a simple network game
      I plan to use this engine in multiplayer game - so, I definitely will evolve the engine. Also
      I plan to add support for mobile devices. And of course, the main focus is to create a toolset
      that will ease games creation.
      Link to repo on source code is - https://github.com/ENgineE777/Atum
      Video of work process in track based editor can be at follow link: 
       
       

    • By mister345
      I made a spotlight that
      1. Projects 3d models onto a render target from each light POV to simulate shadows
      2. Cuts a circle out of the square of light that has been projected onto the render target
      as a result of the light frustum, then only lights up the pixels inside that circle 
      (except the shadowed parts of course), so you dont see the square edges of the projected frustum.
       
      After doing an if check to see if the dot product of light direction and light to vertex vector is greater than .95
      to get my initial cutoff, I then multiply the light intensity value inside the resulting circle by the same dot product value,
      which should range between .95 and 1.0.
       
      This should give the light inside that circle a falloff from 100% lit to 0% lit toward the edge of the circle. However,
      there is no falloff. It's just all equally lit inside the circle. Why on earth, I have no idea. If someone could take a gander
      and let me know, please help, thank you so much.
      float CalculateSpotLightIntensity(     float3 LightPos_VertexSpace,      float3 LightDirection_WS,      float3 SurfaceNormal_WS) {     //float3 lightToVertex = normalize(SurfacePosition - LightPos_VertexSpace);     float3 lightToVertex_WS = -LightPos_VertexSpace;          float dotProduct = saturate(dot(normalize(lightToVertex_WS), normalize(LightDirection_WS)));     // METALLIC EFFECT (deactivate for now)     float metalEffect = saturate(dot(SurfaceNormal_WS, normalize(LightPos_VertexSpace)));     if(dotProduct > .95 /*&& metalEffect > .55*/)     {         return saturate(dot(SurfaceNormal_WS, normalize(LightPos_VertexSpace)));         //return saturate(dot(SurfaceNormal_WS, normalize(LightPos_VertexSpace))) * dotProduct;         //return dotProduct;     }     else     {         return 0;     } } float4 LightPixelShader(PixelInputType input) : SV_TARGET {     float2 projectTexCoord;     float depthValue;     float lightDepthValue;     float4 textureColor;     // Set the bias value for fixing the floating point precision issues.     float bias = 0.001f;     // Set the default output color to the ambient light value for all pixels.     float4 lightColor = cb_ambientColor;     /////////////////// NORMAL MAPPING //////////////////     float4 bumpMap = shaderTextures[4].Sample(SampleType, input.tex);     // Expand the range of the normal value from (0, +1) to (-1, +1).     bumpMap = (bumpMap * 2.0f) - 1.0f;     // Change the COORDINATE BASIS of the normal into the space represented by basis vectors tangent, binormal, and normal!     float3 bumpNormal = normalize((bumpMap.x * input.tangent) + (bumpMap.y * input.binormal) + (bumpMap.z * input.normal));     //////////////// LIGHT LOOP ////////////////     for(int i = 0; i < NUM_LIGHTS; ++i)     {     // Calculate the projected texture coordinates.     projectTexCoord.x =  input.vertex_ProjLightSpace[i].x / input.vertex_ProjLightSpace[i].w / 2.0f + 0.5f;     projectTexCoord.y = -input.vertex_ProjLightSpace[i].y / input.vertex_ProjLightSpace[i].w / 2.0f + 0.5f;     if((saturate(projectTexCoord.x) == projectTexCoord.x) && (saturate(projectTexCoord.y) == projectTexCoord.y))     {         // Sample the shadow map depth value from the depth texture using the sampler at the projected texture coordinate location.         depthValue = shaderTextures[6 + i].Sample(SampleTypeClamp, projectTexCoord).r;         // Calculate the depth of the light.         lightDepthValue = input.vertex_ProjLightSpace[i].z / input.vertex_ProjLightSpace[i].w;         // Subtract the bias from the lightDepthValue.         lightDepthValue = lightDepthValue - bias;         float lightVisibility = shaderTextures[6 + i].SampleCmp(SampleTypeComp, projectTexCoord, lightDepthValue );         // Compare the depth of the shadow map value and the depth of the light to determine whether to shadow or to light this pixel.         // If the light is in front of the object then light the pixel, if not then shadow this pixel since an object (occluder) is casting a shadow on it.             if(lightDepthValue < depthValue)             {                 // Calculate the amount of light on this pixel.                 float lightIntensity = saturate(dot(bumpNormal, normalize(input.lightPos_LS[i])));                 if(lightIntensity > 0.0f)                 {                     // Determine the final diffuse color based on the diffuse color and the amount of light intensity.                     float spotLightIntensity = CalculateSpotLightIntensity(                         input.lightPos_LS[i], // NOTE - this is NOT NORMALIZED!!!                         cb_lights[i].lightDirection,                          bumpNormal/*input.normal*/);                     lightColor += cb_lights[i].diffuseColor*spotLightIntensity* .18f; // spotlight                     //lightColor += cb_lights[i].diffuseColor*lightIntensity* .2f; // square light                 }             }         }     }     // Saturate the final light color.     lightColor = saturate(lightColor);    // lightColor = saturate( CalculateNormalMapIntensity(input, lightColor, cb_lights[0].lightDirection));     // TEXTURE ANIMATION -  Sample pixel color from texture at this texture coordinate location.     input.tex.x += textureTranslation;     // BLENDING     float4 color1 = shaderTextures[0].Sample(SampleTypeWrap, input.tex);     float4 color2 = shaderTextures[1].Sample(SampleTypeWrap, input.tex);     float4 alphaValue = shaderTextures[3].Sample(SampleTypeWrap, input.tex);     textureColor = saturate((alphaValue * color1) + ((1.0f - alphaValue) * color2));     // Combine the light and texture color.     float4 finalColor = lightColor * textureColor;     /////// TRANSPARENCY /////////     //finalColor.a = 0.2f;     return finalColor; }  
      Light_vs.hlsl
      Light_ps.hlsl
  • Popular Now