This article is pulled from my website: www.IndieDevSpot.com the article can also be read here: http://indiedevspot.azurewebsites.net/2014/07/22/note-about-writing-shaders-for-windows/
So you want to write your own shaders do you? OK, I agree, custom shaders really changes the way the game looks. You can quickly and easily stylize your game to look very different from all the other games with a few simple shaders applied to your models and sprites. But you have to write them well. I have helped port a few games over to windows the past few days (5 I think). Anyways, all 5 games had issues with their custom shaders on windows.
As silly as it seems, I often run into teams who seem to think that because their shader works on another platform, the problem inherently lies with one of the largest most advanced OS writing teams in the world and their graphics partners. I have noticed that other platforms will allow you to write ambiguous code or incorrect code and just keep cruising. If the expected behavior of your shader is to be broken and let sprites and models still display properly, then that is your prerogative. I like to know when I have major issues in a core component of my game that already can cause performance issues.
I don’t have some master list, but I have a building list of issues I run into. Lets go over a few right now.
This isn’t even a windows specific issue, this is an everything issue. Know your target platform and the types of devices that support that platform! Lower end devices might only support Shader Model 2. No fixed function shaders or surface shaders here. Make sure you have a fall back or just write your shaders according to Model 2. You should do this if you are targeting Windows Phone 8 or Windows 8. Many of the phones and tablet devices hardware only support Shader Model 2.
While we are still on the device specific issues and not even at the windows issues yet, lets talk a little about Fog. The out of box Unity Fog doesn’t work with Shader Model 3. You have to write your own. Lucky for you, I have found an example one that works. You can view that shader here.
No more short handing your code. Write out your code clearly and obviously for all variables passed between shader stages. I know it “can” be implied, but maybe on my vertOut I want to do something funky and not pass the source position, I want to do something else. Windows will force you to declare what you are passing.
Below actually doesn’t work in windows, but will work on some other platforms.
Below works on all platforms and is more explicit.
float4 scrPos: TEXCOORD0;
If you want more information on this topic, go here. There are a few reasons I think this is a bad idea. The first is, it doesn’t work on Windows. The second is because its a Float4 to a Float2, which two do you cut off? This is just bad practice in my opinion and shouldn’t be done. It is ambiguous and prone to error depending on how this cast is handled between various platforms.
So there we go. Those few problems have accounted for 100% of all shader problems I have run into thus far in which the shader is actually written out and has a chance of working. I highly suggest if you are interested in shader programming to do some additional reading here.