Fixed function worth supporting?

AFAIK, the entire fixed function pipeline is emulated on modern cards using shaders. The question really is: do you care about hardware that doesn't support shaders?

You make a convincing argument. I didn't realized that all fixed-function stuff was actually replaced with shaders.

What is the percentage of cards that don't support shaders nowadays? And by the time I build a game out of this engine, that percentage will lower, i think. Ergo, I'm leaning more towards not supporting fixed-function.

Directx 8.0 inclueded pixel and vertex shader support. Directx 7 cards have not been produced since 2003, but Directx 8 cards began appearing in early 2001.

http://en.wikipedia.org/wiki/Comparison_of_Nvidia_Graphics_Processing_Units
http://en.wikipedia.org/wiki/Comparison_of_ATI_Graphics_Processing_Units

Not unless you plan on supporting DX7-class GPU's. [smile]

Fixed-function is still much faster on older cards, even ones that "support" PS 2.0 (thinking first-generation hardware). However on modern cards fixed-function can actually be slower. IMHO I think it's a good idea to support fixed-function if you want to target older harder and you're GPU-limited, otherwise just go exclusively with shaders and make simpler versions for slower hardware that doesn't do shadow mapping, bump mapping, soft skinning, etc.

Quote:

Original post by RealMarkP NOTE: I heard all about the "Don't make an engine, make games" philosophy. This engine is more of a coding exercise then anything else. A game may spawn form it at once point.

I'm less than certain that you've heard all about it, given that you fail to address the fundamental linchpin of that philosophy: That by coding a game you gain a much better grasp of what you actually need for a game than otherwise (and by extension, what you actually need for an engine), and that by failing to code a game you're far more prone to writing things that you either do not need, or things that you do need but written in a suboptimal manner, both of which are more of an exercise in poor time management than anything else.

I say this because it's a given that a game may spawn from an engine at some point. But an engine can be spawned from a game as well, and the point is that both the game and the engine will generally be better off for it, because you've properly gathered your requirements, something fundamental to software development.

But, whatever, up to you.

http://steampowered.com/status/survey.html
at the moment <5% users dont have shader support this will only get smaller
so IMO no point in worring about it

Quote:

Original post by zedz http://steampowered.com/status/survey.html at the moment <5% users dont have shader support this will only get smaller so IMO no point in worring about it

It's not about whether or not a card supports shaders (namely PS 2.0 and above), but whether it supports them well. An FX 5200 technically supports PS 2.0, however it's horrifically slow. According to the Valve survey, about 15% of the userbase fits into that "slow" category. And a bunch of the cards that default to Shader Model 2.0 (specifically the mobile and express models) aren't so hot either.

At the very least, you should try to support fixed-function for high-fillrate objects (terrain, UI, etc.). It doesn't take that long to add.

For PC or next-gen consoles? Probably not.

For Wii? Definately.

For Gaming Handhelds? Now: yes. Future: who knows.

You forgot to consider what forms the vast majority of installed GPU: the on-board intel processors (i915, i945, ...). Of course, the steam survey doesn't list them because people who have them don't use them to play (they can't; recent games are too big for these). Anyway, they still represent more than 50% of the total market. This is not a good idea to ignore them, especially if you want to tap into the casual game market.

Unless you target a DX10-enabled intel processor, you still have to maintain a fixed function pipeline in your engine. Let's take for example the i945G, which contains the GMA 950 GPU. This GPU supports hardware PS v2.0, but TnL and VS 3.0 are supported only by software. As a consequence, if you want to get fast TnL, you need to limit your shader support and go through the fixed function pipeline. If will still be ran on the CPU but there is a good chance that it will be optimized - while it's more difficult to optimize the shader pipeline. The GMA 900 GPU (in the i915 chipset) is quite similar - only a bit weaker.

Sure, if you target the AAA market, you can roughly forget about those GPUs. After all, your game will need a high end GPU, so why bother? But the fact is that if you ever plan to release a game, it will not be a AAA game - it's more likely that you will produce a casual game. And the casual audience is not the hardcore gamer audience. Their machines are much slower, and you must adapt to them (otherwise they won't buy your game). As a consequence, you'd better take those silly chipset into account.

Sure, that's not teh funnay... :)

How about making a generic interface for your renderer, and write a fixed pipeline *and* a shader implementation?

Really though, if your project is just a coding exercise, it's a question of scope. Writing an engine encompasses a huge number of sub-exercises. I wouldn't worry about supporting a wide range of video cards for just an exercise. Save that headache for later.

I suppose it depends on the audience you are planning on targeting. If you're looking at a casual market then some kind of emulated fixed pipeline would probably be fine. The closer you move to the hardcore market though, typically the graphics use more programmable pipeline (granted, there are complex games using the fixed).

Quote:

AFAIK, the entire fixed function pipeline is emulated on modern cards using shaders.

Development API's are doing this also. XNA GS has a built in class called BasicEffect which is required around your render code that is essentially a shader that simulates a Shader Model 1.1 fixed pipeline. I have no idea about DirectX 10 or OpenGL (since I've only used DX9 and XNA) but I wouldn't be surprised if either had this in an upcoming version. It's to the point where to get a fixed pipeline you'll be writing a shader for that anyways, the only real exception being legacy hardware.

Quote:

It's not about whether or not a card supports shaders (namely PS 2.0 and above), but whether it supports them well. An FX 5200 technically supports PS 2.0, however it's horrifically slow. According to the Valve survey, about 15% of the userbase fits into that "slow" category. And a bunch of the cards that default to Shader Model 2.0 (specifically the mobile and express models) aren't so hot either. At the very least, you should try to support fixed-function for high-fillrate objects (terrain, UI, etc.). It doesn't take that long to add.

speaking as someone whos last card was a nvidia fx 5200,
it was slow at everything, be it fixed function or shaders (mainly due to it having very low fillrate).

whether the app uses shaders or not is not an issue with that card,
in fact from memory there was no diference between the speed of fixed function + shader stuff (remember to use half value precision)

Quote:

Original post by zedz speaking as someone whos last card was a nvidia fx 5200, it was slow at everything, be it fixed function or shaders (mainly due to it having very low fillrate). whether the app uses shaders or not is not an issue with that card, in fact from memory there was no diference between the speed of fixed function + shader stuff (remember to use half value precision)

I did extensive benchmarking on a 5200 for our last game and fixed function was tons faster. Definitely worth keeping around for users without good graphics hardware. Granted it wasn't a fast card in general, but the difference in speed between shaders and fixed function was significant, enough for us to maintain that code path. And Emmanuel brings up a good point about most of the market using integrated graphics.

did u use half data types in your shaders?
the default (at least with glsl + cg + i also assume hlsl) is full precision,
the gffx (unlike the gf6+ greater) iccur something like ~25% drop using these data types.

ie u were prolly benchmarking 2 different things, the shader with higher precision vs fixed function with lower precision, drop the shader precision down to the same as the fixed function + there will be bugger all difference in the speed benchmarks