pouët.net

According to linky, the current Direct3D shader compiler (47) ships with Windows 8.1.

I'm lazy to search for the relevant discussion thread, but anyway... I just remembered a big headache regarding shader compilation in intros, the deprecated DirectX sdk and modern windows versions. This should resolve that problem, am I right?

jsyk :)

It says "The d3dcompiler_47.dll now ships with Windows 8.1." - that still leaves the D3DX DLL's out.

not bad. and you need d3dx @gargaj? what for?

I find the texture loaders convenient.

mkay. but... this' open file. read header. memcpy. demo code stuff. and the missing compiler issue ran on a size code thread. afaik.

I'm sorry, I don't speak Klingon.

i don't either.

I once learned klingon, if I understand yumeji correctly, he means that this discussion happened on a "size coding" thread. On sizecoding you don't really want to load textures from file, you generate them procedurally.

Regarding D3DX, what has been used most was: Shader loading, texture loading and math (vectors, matrices, and their ops).
Shader loading can be done nowadays without much effort with D3DCompile(...). Texture loading is irrelevant for sizecoding, as I said. Math can be done with <DirectXMath.h>. I ported a small dx11 intro framework from D3DX math to DirectXMath yesterday, and it worked flawlessly. The msdn documentation offers valuable help regarding the migration from D3DX math to DirectX math.

So this pretty much sums up, that no modern intro needs to depend on D3DX anymore. This can make life easier for compo orgas, but for developers as well, since all you do is target the Windows SDK.

@Gargaj and if you want to load textures from file, then you're doing a demo. Pick an image loading library, or link to libpng or libjpeg yourself. It doesn't matter. There's always a solution for demos. D3DX is not a necessity anymore, which is my part of my argument. :)

Although there's something there I will miss... D3DXComputeNormalMap with D3DX_NORMALMAP_COMPUTE_OCCLUSION :) gradients and ambient lighting baked for you in one line. Pitty...

How did the discussion shift from D3DX to sizecoding? I'm finding D3DX useful for demos as well.

Image loading libraries tend to have problems (i.e. no support) with e.g. cubemaps or DXT compression.

Useful, yes. Required? I dare to say no.


The main problem was that in D3D9 you couldnt create your shaders with hlsl code without using D3DX. The alternative was to link shader binaries compiled with fxc, which is bad sizewise.

D3D10 introduced D3D10CompileShader which allowed you to compile hlsl from the code without D3DX, but when MS announced that D3DX was deprecated and that not even the shader compiler would be part of Windows, this also meant that compiling hlsl in intros wasn't an alternative, since you shouldn't ship an intro with a d3dcompile_xx.dll

The groundbreaking change now is that Windows 8.1 has that d3dcompile_xx.dll.

I hope you understand now how this is related to sizecoding. Demos never had any problem since they could have had that dll alongside.

For texture loading and some other stuff, Microsoft now offers the open source DirectX Toolkit as a replacement for D3DX: https://directxtk.codeplex.com/

For some more background info on migrating from D3DX to Windows 8/RT/Phone API, here's a blog I did when I migrated my D3D11 engine code: http://scalibq.wordpress.com/2013/04/23/just-keeping-it-metro/

good news that they ship the compiler again.

however, what still sucks is that they recently modified PIX and the debug layer so that you can not use it from VS Express anymore and have to pay for it by buying the full VS version!
You can use Intel GPA as an alternative, but it seemed giving less debug infos.

I don't know why they had to change all this stuff, Win7 + DX11 was such a great platform. For the moment I decided to switch back to GL now..

GL has no issues with shader compilation, but has no built-in texture loading either - though writing that using GDI+ or something similiar will take about 15 minutes :|

(okay, GL has the dreaded problem of sloppy GLSL implementations but nothing related to the compiler itself existing, assuming recent hardware and drivers)

so, next time microsoft makes changes to windows, they better ask permission via pouet first!

sacli: when I look to DXSDK I see the function D3DX11CompileFromFile() and D3DX11CreateTextureFromFile()...

maali, we should also get a couple of sceners into the opengl arb to ensure quality

Yes, but if you read my blog, you'll see that D3DX is deprecated, and is not available for non-x86 architectures (as is the whole DXSDK, the June 2010 release is the last ever. Instead of the DXSDK, you should use the Windows SDK now. Which is also the only way to use D3D11.1 or newer). So if you want to use D3D11 on tablets or smartphones with ARM CPUs, you'll have to use the new libraries.

msqrt: Indeed, but for those who target mobile there's another gotcha: the OpenGL ES 2.0 specification allows to ship an implementation without an on-target shader-compiler. Probably not too relevant for 4k, though.

okish

Hmm.. how should we do this then?
If targeting windows 8 anyway (for instance by requiring dx11.1/2) the right thing is of course to use d3dcompiler_47, but what if we want it to work for both 7 and 8?

Using _43 (d3dx version) means that everyone need to install the June2010 runtime, while using _47 means that it will work out of the box for windows 8.1 (I think it's fair to more or less disregard 8.0 since 8.1 is a free upgrade), but windows 7 users (which still are the majority) will have to manually get the _47 compiler and put it in the path.
Plus the _47 compiler is as far as i remember considerable faster.

(For my converted (test) project it's naturally the right thing to stick to d3dx as it's using d3dx9 anyway for text mesh generation, so no way around the runtime there)

In the mid run, it'll only make sense for compo organizers to offer windows 8.1 as a platform and in the long run, disallow d3dx completely. Who knows how long that'll take.

I guess the compiler would be a way smaller download - probably small enough to ship with the prod and therefore it could just sit next to the .exe? Not sure how mad some people would be would be, though.