   How to shrink down the release size?
  When I used DXSDK 2005 August to build my test application, the release size is 150k.But for that version users should download the 2M d3dx dll.When I switched to DXSDK 2004 December, the dll problem was gone, but release size came to 800k!For d3dx I just use some D3DXMATRIX and a D3DXCompileShaderFromFile.If I comment out D3DXCompileShaderFromFile(), the file size is 280k.Isn't that function shipped with the dx9.0c runtime?I can compile the shader locally and write the assembly into my source to save that 500k, but as to D3DXMATRIX, is there any substitute?Can't imagine that a lib of matrix manipulation takes 100k.It's not a big game software, so even 100k cares.   
  Prior to x version of the DirectX SDK (someone fill in x for me), the D3DX Library was linked statically. So back then, it didn't need any extern dll to work. Currently though, D3DX has put outside of each compiled binary, and is shared in a dll. Which results in smaller binaries.I don't know the exact reason why, but minimizing lots of binarysizes in trade for just a single dll file, does make sense to me.And what's wrong with a 2MB download? If the download is slow or overloading the server, just link them to a local mirror.   ;  Don't forget that you're also supposed to include the C (e.g. msvcr80.dll - 612k, msvcm80.dll - 468k) and/or C++ (e.g msvcp80.dll - 536k) runtimes with your download if you're using them at all.   ;Quote:Original post by raytracer03When I switched to DXSDK 2004 December, the dll problem was gone, but release size came to 800k!That is expected. You're effectively including the DLL directly into your executable. It's a bit smaller than EXE+DLL because the compiler can eliminate and redundant/unused parts. For the more modern DLL it cant do this - its all or nothing.Quote:Original post by raytracer03If I comment out D3DXCompileShaderFromFile(), the file size is 280k.Isn't that function shipped with the dx9.0c runtime?No. D3DX is not part of the runtime - thats why we have to distribute the DLL. HLSL and the effects framework are a completely seperate entity to the core Direct3D runtime. This doesn't change until we get to D3D10...Quote:Original post by raytracer03I can compile the shader locally and write the assembly into my source to save that 500kWhy don't you? runtime compiling of shaders might be easier from a development perspective, but is it really required by your end user? Set up "custom build steps" in VStudio to generate the appropriate binary shader code, ship with that... easy [smile]Quote:Original post by raytracer03but as to D3DXMATRIX, is there any substitute?Can't imagine that a lib of matrix manipulation takes 100k.I dont know - chances are its dragging in more than the matrix functionality. I think d3dx9math.inl contains all of the mathematics code, which should be fairly simple to integrate.Remember that if you really wanted to, you could use D3DMATRIX - you just wont get any of the matrix operators or use any D3DXMatrix**() calls. But if you really wanted you could rewrite these...Quote:Prior to x version of the DirectX SDK (someone fill in x for me)'x' being the February 2005 SDK update [smile]hthJack   ;  Question for JJ.  How dow you compile a shader or .fx file, save it to disk, and then load the compiled stuff into a DX program?  Is it possible to make it a resource?  Thanks!;  Use UPX.   ;Quote:Original post by jollyjeffersI dont know - chances are its dragging in more than the matrix functionality. I think d3dx9math.inl contains all of the mathematics code, which should be fairly simple to integrate.Remember that if you really wanted to, you could use D3DMATRIX - you just wont get any of the matrix operators or use any D3DXMatrix**() calls. But if you really wanted you could rewrite these...This is correct.  The VC linker is pretty smart - just because you tell it to link to a library doesn't mean that it will - unless it has to (ie it finds function calls in your app that are resolved by the library).Since the basic D3DX math structures are just all inlined in d3dx9math.inl (like Jack said), the compiler won't link the entire library (unless you are using other functions, of course).What is really the issue with a few hundred more K?  If your user-base is so old that they are still on 56K, chances are they are going to have to get a new D3D runtime as well - which kinda ruins your efforts here.   ;Quote:Original post by DXnutQuestion for JJ.  How dow you compile a shader or .fx file, save it to diskYou can use the fxc utility for this.  Note that it is located in the Utilities\Bin\x86\ directory.  IIRC, you can't do this with effect files - only raw shaders.Quote:and then load the compiled stuff into a DX program?  Is it possible to make it a resource?Yea, you can make it a resource if you want to.  You can also just load it as a text file.  All you have to do at runtime is call IDirect3DDevice9::Create[Vertex|Pixel]Shader() with a pointer to your block of compiled instructions.There are benefits to using this type of model for shaders.  You don't have to link in D3DX (if you aren't using other components), and you don't have to compile your shaders at runtime (which gets pricy after a while).  However, then you can't use ID3DXEffect, which is pretty helpful and saves a lot of development time.   ;  Seems that if I include <d3dx9math.inl>, I should also include <d3dx9.h>, or else lots of lack of definition come out, for example D3DXINLINE, which is defined in d3dx9.h.But if I include <d3dx9.h>, there's already no need to include <d3dx9math.inl>.So what's that for?I can include <d3dx9math.h> without <d3dx9.h>, although that gave me the same size of binary.Anyway, I'll try D3DMATRIX.To JJ: It's said that runtime compiling can give the best assambly code optimized for the specific card.I don't know how much the difference could be.   