When I started the development of my game according to the then current Steam Hardware survey almost 10% of the gamers still only had Shader Model 2.0 available so I decided to write all effects (some of them gameplay related whereas they could not be optional) with the restrictions of said version.
Today the percentage is a different one, less than 1.5% of the Steam users have a graphics card that does not support SM 3.0, and as the restriction to SM 2.0 notably limits my ability to write effects and currently even prevents the implementation of one gameplay element in a level I am thinking about a complete switch to SM 3.0, meaning that my game would not run on weaker graphics cards.
Is there any reason that speaks against this choice?
I have written almost 200 shaders so far for my game, all compiled with 2.0. Does it have a benefit if I compile all of them with 3.0 instead? Only a few of them have an "if" statement, does 3.0 handle those differently?

You could have fall-backs where you detect the card and fire up the appropriate version for that card...

No, as I've said, I cannot (!) do that and I think you can imagine that I already know that method.
Some effects cannot be implemented with 2.0 and when the gameplay/ level is based on those a fallback is worth nothing.

I'd use SM3.0 since every DX-9.0c card supports it and 9.0c is already 9 years old.
Besides that, I don't think a graphics-card which is so old that it doesn't even support DX9 will be fast enough to run your game.

I would never consider to limit myself to nasty SM2.x because of those 1.5%

hmmm.. interesting. your game fits a lot more than steam gamers though, I can see it fitting in well in a lot of casual and young gamers. That, and the obviously large amount of effort you put already into keeping it 2.0 safe, I'd say to see if there is maybe a way to make that particular element work on 2.0 even if it is done by modifying the element specifically on 2.0 cards or even omitting it for players that play on a 2.0, by specify that there is some content that is current hardware compliant only?

It just seems to be a waste of all that effort, and a very viable demographic for your game. I can see many small children playing this who may never have heard of nor know how to use steam. Do you plan a box version of this game?

There is absolutely no reason not to use a higher shader model, because about every laptop and desktop computer sold in the last 6 years or so will support at least shader model 3.0, most even 4.0.

I think I once read, that one should use the highest possible shader model, because of a better shader compiler being used then.
On the other hand I read somewhere that one should use the lowest possible profile for CG, for additional optimizations or something, but that probably doesn´t count for HLSL.

Dynamic branching will be used with shader model 3.0, which can be a performance problem if there are many branches and pixels close to each other, all use different ones, but in your case that should not be a problem and dynamic branching could be in some special cases an opportunity to improve your shaders performance.

Thank you guys for the replies!
I'm not sure where and how I want to sell my game but casual gamers would just be frustrated with the game as it is really hard to play and somehow unforgiving to the point as you don't have a lifebar and there are no checkpoints.


Can you please take the time and try to explain this a little more? Is there a time when a shader with an "if" is better to be compiled with PS2.0 than with 3.0?
One of the shaders where I need to make if comparisons is a single layer non-overlapping model, almost screen filling.

Well in that case, yeah, I'd agree with everyone else, go 3.0. The game looked like a simple platformer with some action elements, but if its that challanging, i could definitely see what your saying. I'm quite excited to see it released so I can try it.

@Superku: The potential performance issue with dynamic branching comes from frequently switching the branches, which is the case when you have rather small pixel patches for which the same branch will be taken. To prevent dynamic branching you can use the [flatten] attribute. No need to use a lower SM. There is also [branch] which forces dynamic branching, but my experience is that the compiler guesses quite well whether to flatten the if statement or not.