Hi - please bear with me I am quite new to all stuff graphics related. Here's a post I made on another forum but I was advised to head over here instead. So here's some thoughts I have which I need help with. Thanks:

I'm in the process of actually making a game. It has finally happened after many years of waffling and talking stuff that sounded good.

I've pretty much got to the end of my DirectX learning curve for now I can do most things I would want. I can load an animated mesh with the Hierachy function and allocation class, load textures, load models, select objects on screen, make a game display make lights all that stuff.

I'm also ok with physics and stuff now having spent alot of time thinking and reading about it and I'm also into collision detection. Pretty familiar with the game loop and hierachy layout and how all this happens after being called from within a windows function. Great.

But. The last area of my DirectX learning has wandered me into pixel shading. The correct term I believe is HLSL - High Level Shader Language. Seems now it allows one to address the graphics card processor directly to produce nice effects. Ok fine. It also however means extra compiling to be done and I'm worried about this might be happening at run time as it's quite an abstracted language above even C++. Ok but modern processors should be able to handle this right?

The further thing I'm worried about is compatibility. I do have the money to get another graphics card if I want but I intentionally have run all my directX stuff so far without a graphics card using the processor to do all that emulating stuff.

I wouldn't have been worried but the first time I tried to compile and run the C++ source file with the effect file (the effect file is a .fx file which holds the shader language) the machine went blank, nothing showed and windows complained of a problem and had to close the application (program). No doubt because of a bad communication between the shader language and on board card simulator being run by my processor. I thought however shader language was supposed to hold a technique function. The shader file I have does have one yet for some reason it could not properly source an acceptable technique for my on board card emulator and crashed the program.

So with that said here's the deal:

The game I'm writing is based on out and out gameplay. Having played WWIIOnline I've seen just how much market there still is for very basic graphics (by today's standards) provided they're backed up by amazing gameplay - which World War II Online (also termed BattleGround Europe produced by Cornered Rat Software) definitely has. So I'm wondering do I *really* need to use HLSL and pixel shaders? The DirectX effects I've seen so far looked very good to me and quite capable of rendering an acceptable game world that's lit very nicely and accurately. They also give access to all required texture filtering such as Anisotropic and all that stuff.

I do not want to write a game which irritates users at the sharp end by refusing to run due to compatibility problems. I've also noticed that with DirectX I can access pixel level I believe so I could even code my own basic stuff into that for things like blur effects or haze effects usng some sort of circle around which a mean average of pixel values was took, and this average was then redistributed back to the pixels - creating a blur. I really don't need my models to look like they're covered in crude oil during a gorgeous sunrise.

So to summarise my two camps of thought:

1) Leave pixel shaders alone.

Pros

- Big bonus in compatibility and speed.
- Can do everything I'd want to anyway.
- Avoid what looks like a giant non-standardisation based mess in the industry.

Cons

- Can't have easy to use special effects.
- I'd have to make any effects I wanted myself.
- Game doesn't look as pretty especially around water and stuff.

2) Use pixel shaders.

Pros

- It's reasonable to expect a gamer to have a low level card.
- Easy to use effects.
- Extra nice looking game for not much effort.

Cons

- Get drawn into compatibility mess caused by multi manufacturers. Maybe some cards (no matter how expensive) may not work at all if they don't support a specific shader no matter how powerful.
- Risk irritating customer base and forcing them to spend money (which is something I don't believe in doing when you're supposed to be providing a paid for service to someone).

So there it is. I'm not sure what to do. I have LOTS of sympathy with people on a budget or having to use their friends/parents/aunties machine. I do not want them to be excluded. At all. I'd prefer a less nice looking game with more time spent on improving gameplay rather than just drafting in 3rd party made shader files to make the game look good so it sold and then dumping the responsibility of that onto the customer by making them having to pay yet more money to get it to run (which is something I'm sure is rife in the industry at present).

So please can someone help me out here? I just want the best compromise between nice effects and compatibility, but very much leaning towards compatibility. I realise I may also be worrying too much here. Perhaps the industry is more standardised than I think it's just my lack of knowledge that makes it appear so.

Update*
I would also like to add that my card emulator (chipset or whatever it's called) has actually run some shader programs now but it never shows the mesh only the background I cleared the back buffer too. I would really like to get a shader to run with this on-board rig before I would trust using it as part of a game I distributed.*

Thanks

Ok I actually got one to run. Ok I'm sold on it for now. They do look very good. I could still use some answers to my questions above though.

I do apologise for my threads as they often get way out of control with information overload. My usual haunts are ok with this as I've been around them for so long so people know just to tolerate it. I do worry about how that will come across though when I go somewhere new!

Any input at all would really help thanks. I've decided to start learning about these shader files afterall. I'm still not convinced though as I am worried about frame rate hits, or at least I will be till someone comforts me on that one.

The only real thing I can see that has to be answered sooner or later is shadows. Given that there will be some moving light sources in the game, I'm wondering if perhaps I have no choice but to use a shader file as I'm told they're required to make proper light reactive shadows for when say a car with headlights drives past a building. But then I'm wondering do I really need this effect. Confused? You'd better believe it!

I think NOT using shaders is pretty much losing the whole point of you are programming in 3D.

Coolest things are done with shaders :)

Your shaders can be compiled in advance and shipped in your game so that you don't have to spend any run time compiling cost. It may also not be much of an issue anyway if you only have a handful of simple shaders that you can compile once when the game starts.

I assume that you're using dx9 since you want maximum compatibility? As a reference for dx9 feature compatibility consider looking at the d3d11 feature level 9.1. The list of features given here are the most consistent across all hardware and will help you avoid features that are known to have trouble for some or many IHV's. The D3D SDK should also ship with a dx9 compatibility chart still that shows which hardware supports various features. The chart is quite large so it's probably easier to just refer to the feature level for the distilled version.

Using Effects vs individual shaders comes down to your preference for how you'd want to manage the pipeline.

Well I think all these replies are great.

It gives me a good benchmark now having read what you guys have said. Seems shader model 2 is the standard to be working with and the feature thing mentioned gives me a much better idea of something I can work around so I avoid compatibility issues in advance.

This clears alot of sparking loose ends up for me thanks all so much ;)

Just to let you know thanks to the insight I've had from here and the fruits of much of my own labour I've now got a good looking reflective shader to run. Even found a major error in the online tutorial's shader file and fixed it. It wasn't assigning new colours to vertices or returning the new altered vertex array.

Seems this is happening fast now I'm well up to speed with it all. Normally does happen that way to be honest if I really attack something. Seem to go from knowing nothing to knowing enough to correct other people's mistakes in about 24 hours.

Anyways, thanks ;o) !

Also, even if you run dx in software vertex proccessing mode, rasterizing is done on GPU, so if you compile pixel function with 3.0 target, you will not run this shader in software mode if GPU does not support 3.0 target.

Target 2.0 and 3.0 are limited in number of instructions, since target 4.0 is unlimited, but 4.0 target can be used only with directX 10 or higher.

On the whole though, I find graphics programming difficult, shaders or not. The reasons for this difficulty are (1) not good enough maths skill [something I'm correcting with some courses] and (2) sending numbers into a black box and then having to use sometimes inadequate debugging tools to find out whether what I sent in, or how I configured the black box was correct. This is notwithstanding the differences between graphics hardware (pre DX10) where some things you try work and some don't!

If you don't get it right away, it's just because it's difficult :p.