The game shaders...

[irishrailguy]

Hi,

So this is a topic that doesn't seem to get brought up at all about TS2014. Maybe it's because it's rather scary and leaves people confused But does anyone on here experiment with the HLSL shaders provided in the 'dev' folder of TS2014?

I was reminded of my previous efforts on these shaders before, when the subject was brought up in the 'on going projects' thread. I had attempted to re-write parts of a shader provided in said folder, with no differing outcomes. Despite most games being written with the DirectX libraries, there's a very scattered community of HLSL 'activists' on the web that provide teaching support or general discussion/experiments with .fx files.

I know Jordi has worked with the shaders in the past, but I'd rather not bother him again about another topic I can't seem to grasp as well as him I attempted to try and talk to someone over at DTG about the shaders and how they composed them, but emailing support resulted in a 'fob off' email basically telling me that I shouldn't be messing with their shaders, which is a bit odd considering that they've provided their source material to the user...

So on to my issues, if anyone even has an answer Basically I wanted to start out by seeing if I could add a small effect to one of the shaders, so I chose TrainBumpSpecEnvMask.fx. I opened it in VS2013 and the syntax seems relatively similar to C/C++, of which I have a year's college experience in, so I wasn't too bothered about that. It took a good bit of reading to understand how shaders worked, but I grasped that color/effect changes mostly happen at the pixel shader stage of the rendering pipeline, so that was where I needed to make changes. As far as I've been able to discern, here's my concept of how a shader works:

-the shader takes in vertex/index data
-the data is transformed to screen projection coordinates with vertex shaders
-the vertex groups are rasterised into polygons
-the polygon space occupied on-screen is allocated pixels on the screen
-these pixels are colored by the pixel shaders given lighting data/normals etc.
-the techniques are the last part of the .fx file where the desired vertex shader is compiled, then an accompanying pixel shader adds the desired effect to the given pixel.
-multiple techniques can be used to layer basic effects together in multiple passes to create something complex like TrainBumpSpecEnvMask.fx

I took a sample effect off the web that is supposed to take a given pixel's coloring data and convert it to greyscale. Here's the code:

Code: Select all

float4 greyscale(float2 texCoord : TEXCOORD0) : color0
{
   float4 colour = tex2D(diffuseSampler, texCoord.xy);
   colour.rgb = 1 - colour.rgb;
   return colour;
}

I thought that I would see if I could actually modify DTG's code to produce a new effect. Admittedly I didn't (and still don't) know whether what I was doing was actually correct, in fact I didn't even know what I was doing, I just followed the example that the existing code provided me. I don't know if the above example code does what it says it does (don't know how subtracting the rgb values from 1 gives the greyscale), but I went with it anyway. So I stuck this greyscale pixel shader in below the other pixel shaders (below TrainPSLow() ) and thought it would need to be put into a technique/pass to be put into effect in-game. So I first created a new technique with the exact same syntax as the one above it (the LOW technique) and gave it a different name (TEST). I changed the pixel shader used in that pass from TrainPSLow() to greyscale(), saved the file and compiled it with DirectX's utility fxc.exe. After a bit of fidgeting with the compiler, I got the .fx file compiled into an .o file. I thought that was great, no compiler errors so I wasn't doing anything wrong (I had to change the texture sampler name so that it used the one from the shader and not the example one, which solved previous compiler errors). I overwrote the old shader object file (I made a backup ) and went in game to check it out.

So I was expecting that anything which has TrainBumpSpecEnvMask.fx applied to it in-game would appear in greyscale. But surprisingly, nothing had changed. All my rolling stock rendered in color as it used to, which I found odd as I thought that if I did something wrong then the shader would behave weird in game, but nothing was awry. So I decided to see if I could actually break the shader to get some sort of response to show that I was making an impact. I decided to remove all techniques except the deferred one (fxc threw an error if I removed them all), but amazingly without 3 of it's passes, anything in game with the shader applied looked no different than the 4-pass version.

So if someone on here knows anything about shaders or has successfully modified them, would they mind inputting on this? I'd like to get into the proper stuff of graphics, I think this could be very useful to me in the long run.

Thanks,

Kevin

[irishrailguy]

Oh, wait:

It appears as though I didn't realize that game code is cached, so my changes weren't happening until I restarted the program

I came back today to find that all trains were see-through, I remembered that I had removed the 3 render passes and noticed that the colors of the train were still showing up through the transparency. So I decided to take a look at it again to see whether I could re-code a greyscale pixel shader. This time I decided to use my own intuition, figuring that the RGB values must all be the same to be a shade of grey. I took the average of all three channel colours and then reassigned that average to the diffuse channel values. I did this in the deferred pixel shader so I wouldn't have to extract the struct data again and run it through another pass.

I must admit I'm pretty chuffed that this worked the first time round, without any odd effects or other things happening. I'm aware that it's profoundly basic, but I can't believe it actually worked Here's the code if anyone wants to look (including some of the deferred shader code for relevance):

Code: Select all

DeferredPSOut TrainPSDeferred ( v2fd IN )
{
   DeferredPSOut output;
   
   float4 diffuseColour = tex2D ( diffuseSampler, IN.TexCoord0.xy );

   //average the rgb values

   float greyscale_avg = diffuseColour.r + diffuseColour.g + diffuseColour.b;

   greyscale_avg = greyscale_avg / 3;

   diffuseColour.r = greyscale_avg;
   diffuseColour.g = greyscale_avg;
   diffuseColour.b = greyscale_avg;

   /////////////////////////////////////

   output.Diffuse = float4 ( MyColourConstant.rgb * diffuseColour, MyColourConstant.a );

   return output;
}

Kevin

[MikeTrams]

You might be able to edit them but making new ones might be difficult. I'd imagine the code which calls them is compiled, I like to read through them but I never tampered because I know that no one else would admire them.

Cheers,
Mike

[cjbarnes5294]

Very interesting find, Kevin.

Chris

[irishrailguy]

You might be able to edit them but making new ones might be difficult. I'd imagine the code which calls them is compiled, I like to read through them but I never tampered because I know that no one else would admire them.

Cheers,
Mike

Hi Mike,

They are easy enough to edit indeed, I'm aware that it's probably impossible to add a new shader without the source c++ code for the game itself though. They are all hard-coded into the game's DirectX interface from what I can tell, plus you'd need to add them to the 3DS Max plugin too, which would also be a pain.

But I can't be sure, which is why I'd really appreciate DTG to just allow me to talk with one of their DirectX programmers, but that's not going to happen...

However, in terms of effects it's perfectly fine to add new code to the existing pipeline of any shader already available. They all cover what's basically needed to compose the game visuals, so adding to them should suffice for anything reasonable (Unless you wanted a toon shader or something ridiculous like that )

Kevin