# Continuing support of FFP

## Recommended Posts

I know this question has been asked before (back in Oct/Nov. '05 timeframe), but I can't seem to find the relevent thread, so I must bring up the topic again. Up until now I've been coding my graphics engine with the FFP. If I were to want to change it to a shader based engine, I have a question. Can I drop support for FFP and reasonably expect that any card a game made with my engine runs on will have at least SM 1.1 support? I realize keeping FFP support is the prudent thing to do, but I don't want to get that far into coding the FFP just to find out that most cards out there have SM 1.1 support. Thanks for any input. -AJ

##### Share on other sites
If you want to become a user of ".fx" files, then this is your lucky day!

While fx library is used mostly to write HLSL shaders, it also supports FFP. With this in mind, you can safely forget about FFP in your engine, and drop the responsibility on external files (which you should do anyway (I mean data-driven programming)).

Whenever someone will be bugging you about releasing FFP version of your game, you will just re-write some text files and don't even touch the code.

Cheers.
~def

##### Share on other sites

GeForce256 was the first /consumer/ card to support FFP T&L in hardware (IIRC 3DLabs had workstation H/W T&L cards out before them, despite nVidia's marketing claims).

For pixel shaders, GeForce3 was the first ps1.x based card out there; for vertex shaders there's always software vertex processing on the CPU...

GeForce3 was released around 2001, that's hardware that's 5 years old. GeForce256 was released in around 1999...

My laptop is a ~2.4GHz P4 with a GeForce 6800 Go.

My mothers PC is a ~P200 with (I think) a Matrox Mystique.

The point?

What level of hardware you support depends on the target market your engine/game/product is aimed at - and how much time you have to implement multiple code paths ('all' is a no brainer when you have all the time in the world...).

For the most casual end of the 'casual' market you can safely assume "3D Rasterization" in hardware and not much else.

For 'gamers', I think shader 1.1 support is a 'safe' base hardware requirement.
However, I'd still be tempted to have an optional "software vertex shader + hardware FFP pixel processing" optional fallback path - assuming I had the time to implement that on top of the usual shader path.

For the 'hardcore' (i.e. people who play FPSes on their PCs), shader hardware is a given.

If your engine is aiming to show off lots of cool graphics effects, I'd say it's worth starting at the higher/top end of your target market and porting backwards to get the best/most acceptable version of each of your effects.

##### Share on other sites
Quote:
 Original post by defferIf you want to become a user of ".fx" files, then this is your lucky day!While fx library is used mostly to write HLSL shaders, it also supports FFP. With this in mind, you can safely forget about FFP in your engine, and drop the responsibility on external files (which you should do anyway (I mean data-driven programming)).Whenever someone will be bugging you about releasing FFP version of your game, you will just re-write some text files and don't even touch the code.Cheers.~def

Many thanks for the reply. Could you elaborate on that, though, please? How can a game written in all programable pipeline be changed to use FFP just by changing some text files?

Quote:
 Original post by S1CAFor the most casual end of the 'casual' market you can safely assume "3D Rasterization" in hardware and not much else.For 'gamers', I think shader 1.1 support is a 'safe' base hardware requirement.However, I'd still be tempted to have an optional "software vertex shader + hardware FFP pixel processing" optional fallback path - assuming I had the time to implement that on top of the usual shader path.For the 'hardcore' (i.e. people who play FPSes on their PCs), shader hardware is a given.If your engine is aiming to show off lots of cool graphics effects, I'd say it's worth starting at the higher/top end of your target market and porting backwards to get the best/most acceptable version of each of your effects.

That's exactly the opinion I was looking for. Many thanks [smile]

-AJ

##### Share on other sites
Quote:
 Original post by u235Many thanks for the reply. Could you elaborate on that, though, please? How can a game written in all programable pipeline be changed to use FFP just by changing some text files?

That's the magic of FX files. Basically, your engine creates an ID3DXEffect, loads it from a file, and enables it while drawing the corresponding subset of a mesh.

Psuedo-code:
ID3DXEffect effect = LoadEffectFile("effect1.fx");effect.Start();mesh.Draw();effect.End();

All the details of FFP and pixel/vertex shaders are hidden in the ID3DXEffect. Now, if you plan on using pixel/vertex shaders, there are some other things you have to do, but that's inevitable, whether you use FX files or not.

Good luck!

##### Share on other sites
Quote:
 Original post by u235Could you elaborate on that, though, please? How can a game written in all programable pipeline be changed to use FFP just by changing some text files?

An example is worth more than a thousand words. A snippet of a technique description in an .fx file:
// using programmable pipelineVertexShader = compile  vs_1_1  MyPreviouslyDefinedVS();PixelShader  = compile  ps_2_0  MyPreviouslyDefinedPS();// using FFPVertexShader = NULL;PixelShader  = NULL;ColorOp[0]   = SelectArg1;ColorArg1[0] = Texture;AlphaOp[0]   = SelectArg1;AlphaArg1[0] = Diffuse;ColorOp[1]   = Disable;// ...and so on, just like you would do in a real C++ code...

For details, look into DX SDK documentation (as usuall[smile]).

##### Share on other sites
Quote:
Original post by deffer
Quote:
 Original post by u235Could you elaborate on that, though, please? How can a game written in all programable pipeline be changed to use FFP just by changing some text files?

An example is worth more than a thousand words. A snippet of a technique description in an .fx file:
*** Source Snippet Removed ***

For details, look into DX SDK documentation (as usuall[smile]).

*Drop jaw in disbelief* I had no idea you could do it like that. Thanks very much for the heads up [smile]

-AJ