Are Valve going to update the shader system to allow for shader version 3.0?--Pon 17:21, 5 Aug 2005 (PDT)
- I think I read somewhere that for the HDR stuff to run fully users will need cards supporting shader version 3.0 - so the answer is, presumably, yes? --Cargo Cult 06:13, 6 Aug 2005 (PDT)
I've started the (slow) process of cleaning the article up, I've worked through to Anatomy of Shader DLL Code so far - which means the easy bit's near enough done. I've re-organised it slightly and swapped the POV but otherwise left the majority of the early content alone.
I think I'll need to spend some time over the next few days figuring out how to sort the rest of the information to be a) more readable b) easy to follow and c) more useful in general. --Ging 20:00, 1 Aug 2006 (PDT)
Anybody get sdk_vertexlitgeneric dx9 working?
So I've been able to get the dx8 version up and running but haven't tinkered around with it much since it's asm. There's some things that need to change in the SDK. the #includes in basevsshader_vertexlitgeneric_dx9_helper.cpp need to have "sdk_" prepended to them, and I needed to add a #define dx9 1 to the file to get the thing to compile correctly. After all this it runs the thing, but I just get white back as the color. Anyone been able to get this to work like the normal vertexlitgeneric?
Has anyone gotten the light map to actually come in on the samples?
I've tried with the sdk_lightmap shader and I've compiled the advanced/SDK_LightmappedGeneric shader and tried with that.
Either way I don't get a valid lightmap in. It seems to be just all ones, and the lightmap texture coordinates seem to come in as 0.0 0.0 everywhere. (As far as I can tell that is.)
I have had no problems with the straight up "lightmappedgeneric" shader, so I am wondering if there is a step that I'm missing in the compilation of these shaders. (The textures and the projected coordinates come though fine though.)
I'd appreciate any comment. Even someone saying that they havn't had any problems. I have been pulling my hair out over this for quite little while.
December DX9 sdk doesnt seem to work
I get Internal error: conflicting range data when compiling some of the shaders
This is out of date, (as of February 18th 2010)
I tried to follow this article, but everything is changed. Some of the perl scripts were replaced or rewrote. And it would seems the compile code is able to handle orange box shader compiling now.
The fixes are all irrelevant, the only thing to change is two lines from buildsdkshaders.bat
the GAMEDIR needs to be set and the SDKBINDIR needs to be set, then it should help you getting the shaders to compile.
rem ================================ rem ==== MOD PATH CONFIGURATIONS === rem == Set the absolute path to your mod s game directory here == rem == Note that this path needs does not support long file/directory names == rem == So instead of a path such as "C:\Program Files\Steam\steamapps\mymod" == rem == you need to find the 8.3 abbreviation for the directory name using 'dir /x' == rem == and set the directory to something like C:\PROGRA~2\Steam\steamapps\sourcemods\mymod == set GAMEDIR=<SET ME> rem == Set the relative path to SourceSDK\bin\orangebox\bin == rem == As above, this path does not support long directory names or spaces == rem == e.g. ..\..\..\..\..\PROGRA~2\Steam\steamapps\<USER NAME>\sourcesdk\bin\orangebox\bin == set SDKBINDIR=<SET ME> rem == Set the Path to your mods root source code == rem this should already be correct, accepts relative paths only! set SOURCEDIR=..\.. rem ==== MOD PATH CONFIGURATIONS END === rem ====================================
--psycommando 02:11, 19 February 2010 (UTC)
Cleaned up and updated
I cleaned up a lot of the outdated stuff previously mentioned. The process is much more streamlined and easier now. I also added some clarity and tips in areas that weren't specific enough. --Cman2k 09:23, 6 May 2010 (UTC)