In the development diaries there are mentions to several different features you implemented like parallax mapping and bloom for instance. Could you tell us what will be the minimum Shader Model version supported by the renderer and if you are shipping with a high level shading language or straight shader assembly?
We had to go with assembly, mainly because of support for the XBox' shader model 1.1. So we ended up having two versions of our shaders, one for the 1.x shader path and another for 2.0. Well, parallax mapping just couldn't fit in 1.1 (nor 1.4, unfortunately), but we do have support for the bloom effect in the 1.x path.
Also, since SM3.0 is something you wanted to code in high-level shading languages, it didn't make much sense to squeeze that one in, also. Today, most of the SM3.0 effects, you can do with 2.0 shaders, but don't get me wrong - this will surely change very fast. And not to mention that SM3.0 is _much_ better for programming (looking from non-marketing, just developer's perspective now :). I personally can't wait to ditch PS1.x completely, write all the shaders in 3.0, and have a fall-back path for 2.0.
Have you experienced any difficulties with creating the same shader for the various SM versions with regards to precision, instruction count, etc?
"Difficulties" is just not strong enough word! Try with "headaches", please. :) Yes, it tends to be really, really hard to squeeze a nicely written 2.0 pixel shader into 1.1.
For example, our Terrain shader has 1 pass on 2.0 HW, 2 passes on 1.4 and even 3 passes on poor old 1.1 pixel shaders. With all the properties and options it has, 8 instructions can be really painful. On some occasions, we actually ended up having 20 instructions PS1.1 (4 textures, 8 instructions and 8 co-issues). Perfect fit, isn't it? :)
Could you also tell us if either SM 2.0a or 2.0b are used by SS2?
No, no SM2a/b, thank you. Let me just sidetrack here for a moment, just to say that I'm not buying PR-crap that NV and ATI throws all around. Yes, I'm referring to "countless" number of instructions in shaders. I thought game developers are guys that optimize the hell out of their code. And it should stand for shader-code also! In that light, I don't see the point of having 100+ (heck, even 50+!) instructions per shader for a game, especially if you can make (almost) the same visual appearance with ~30 instructions. And you can!
So no, we don't have long shaders in "Serious Sam 2" and we're proud of it! :) I believe that gamers want the game that runs and plays well, not a slow-mo demo for newestcoolest3dfeatures(tm). And we put a lot of work in optimizing the shader usage for Sam2 in order to make playable frame-rate with lots of action on screen.
In every GPU generation there's talk of the mythical Displacement Mapping but it never pans out; with the advent of SM 3.0 and its texture fetch in the VS do you think this time it will pick up or do you think the latency in fetching textures is just not acceptable right now?
Well, there are always some performance issues with new features in the beginning, so I wouldn't look just from the perspective of how it fits in rendering pipeline "right now". Displacement Mapping does have a nice potential and I think it will be used in the future, at least for cloth and/or water animation.
