HLSL (Pixel Shaders) Should I just walk away?
Members - Reputation: 271
Posted 18 June 2010 - 12:22 AM
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.
- 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.
- 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.
- 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.
- 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.
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.*
Members - Reputation: 271
Posted 18 June 2010 - 01:16 AM
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!
Members - Reputation: 700
Posted 18 June 2010 - 05:28 AM
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.
Crossbones+ - Reputation: 7344
Posted 18 June 2010 - 11:38 AM
Compatibility-wise you need to pick your target hardware and code to that. Bear in mind that shader model 2 is supported on even Intel 915 integrated graphics, and can run quite fast there. Where you might run into trouble is if you're also targetting GeForce 4 (or ATI equivalent) or earlier hardware, because if you choose shader model 2 (and anything less is really baloney - even if it was great at the time) you're restricting your potential user base. This might not be as bad as it seems...
Of your potential user base you can roughly divide it in two. Hard core gamers will have high end graphics that will eat this stuff for breakfast and come back looking for more. Non gamers will have the Intel integrated stuff, but that also works fine.
A third group will be those who have crusty and grotty old hardware and have no intention of upgrading it. It's up to you whether or not you want to target those.
If anyone has Windows Vista or 7 they will have shader model 2 support minimum; full stop.
If you ever want to upgrade your app to D3D10 or 11 then you have no choice but to use shaders. Using them now will ease the transition.
Right now I'd say ditch the emulator, grab a version of the DirectX SDK from 2005-ish, and use that. Run some of the samples from it and see how things go on your machine.
Members - Reputation: 271
Posted 18 June 2010 - 12:12 PM
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 ;)
Members - Reputation: 271
Posted 18 June 2010 - 03:44 PM
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) !
Members - Reputation: 161
Posted 19 June 2010 - 02:39 AM
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.
Members - Reputation: 100
Posted 19 June 2010 - 03:32 AM
If you don't get it right away, it's just because it's difficult :p.
Members - Reputation: 100
Posted 21 June 2010 - 04:09 AM
Members - Reputation: 271
Posted 21 June 2010 - 08:33 PM
Afterall I might need help with GUI's at some point.
Members - Reputation: 664
Posted 12 October 2012 - 06:12 PM
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 .
I would be in the same boat if I started using Shader scripts (my learning curve).
Doesnt someone out there have the old style effect editor that allows you to test effects immeiately (wizard interface) and then kicks out the shader scripts needed to run the same effect (even simple ones)??? I remember they had them to test settings of the fixed function pipeline long ago.
That at least would generate examples that could help learn manual script generation.
I would be looking at doing collision IN the GPU which would liklely be beyond any 'effect eitor App' , but since I largely stayed away from that programming area anything even to get the process of using shader scripts would help flatten the learning curve. It would eventually lead to looking online for more exact examples, but you have to understand the basics of the script structures/process first and its better to have actually run simpler examples than just read about them
Members - Reputation: 551
Posted 12 October 2012 - 08:10 PM
- Less work to do
- Don't have to learn anything
- Won't have shader errors
- Your game won't have to slow down to compile them, ever
- You can't actually get anything on the screen... lol
Anyway, shaders are amazing. And once you get familiar with them you will love em. Shaders give you complete control over how things are rendered in several stages. DirectX10, for example, gives you control over the vertex, geometry and pixel processing stages. DirectX11 has all of these and also gives you compute, domain and hull shader stages. You can just use very basic shading techniques if you like, but the capability is there to do beautiful and amazing things that will take your breath away... everything from simulating realistic water surfaces to GPU-accelerated physics to smoke, fire and explosions. What you can do with shaders is limited only by your imagination and the hardware its running on. All of these things you're worried about are complete non-issues... If compiling shaders at runtime is too slow for your game then just pre-compile them... Shaders are NOT an "un-standardized mess"... HLSL is completely "standardized", as is GLSL for OpenGL. Graphics hardware and their capabilities are the only thing that's not "standardized" and uniform across the board, but that's not the fault of shaders or shader languages.
If you want to get anywhere in game developing for any purpose, be it hobby or commercial, then you're going to have to learn shaders. Otherwise I dunno how you plan on getting a single pixel to show up on the screen or doing anything expected of a video game in modern times. ;-)
As for WWII Online, I played that game for several years and was sorely disappointed... I think it's a very poor example to follow if you want to develop, and CRS is a poor example to follow for a company. At the time I was playing the game regularly I could understand the very poor graphics, but it's been years since then and their graphics are STILL bad... almost exactly as bad as they were 4yrs ago... There's little excuse for that, imo... But hey, graphics aren't everything, right? Well, their physics are also terrible...particularly the flight models. As someone who's VERY into aviation (loved flying since I was a kid) and flight simulations it was one of the most disappointing things about the game. One of the worst things about the whole game, imo, is how they try to "balance" the Axis and Allied sides and still call it a "simulation". In war there is no "balance" except the other guy shooting at you, and there should be no notion of "balancing" equipment performance in a simulation. Tank combat is very quirky and full of utter ridiculousness... small Allied guns can sometimes plink a German Tiger a couple times, FRONT ON, and set it ablaze...which is absolute fiction. Infantry combat was always very boring and full of its own problems... the controls are very "static" and old school, you really cant do much more than run/walk/shoot/reload (no dropping weapons, picking up new ones, etc)... they didn't even bother to implement real small arms ballistic physics (they just use range table data and calculate a path, afaik)... About 95% of the time you're playing the game you're bored because you never see enemies. And the reason you never see enemies is because not enough people play. And the reason not enough people play is because A) the graphics suck B) it's not very realistic C) they don't update/fix things in any reasonable amount of time.
One of the main reasons I say CRS is a bad example to follow as a company is all because of their lead programmer (that guy, DOC). He goes on the forums and will actually sit there are argue with players, belittle them and try to make them feel stupid; especially if they suggest changes/upgrades for the game or criticize something that's wrong with it. Those are their CUSTOMERS... a game development company should NEVER try to make a customer feel stupid or try to make them look stupid in front of other people on the forums. If I was the CEO of CRS he would be the first person I fired simply because of that, and I would fire anyone else who did it and also get rid of all their forum moderators who engage in the same behavior. That sort of crap has chased off a good many players from whom the game could have benefited greatly (if anything in numbers lol). The other reason I say they make a bad example is, well... look at how outdated their software is. It has changed very little in, say, a decade... There are much smaller companies and indy developers spitting out vastly superior (complete) products faster than they fix a bug or do a minor update/patch. Don't go on the forums and bring that up though, because you will get attacked by DOC or someone else. They'll make a huge wall-o-text post full of excuses about why the game can't be fixed that makes absolutely no sense. I remember one time, for example, we were discussing the possibility of allowing pilots to bailout of their planes and parachute to safety (I think the game has that feature now but didn't at the time). DOC chimed in and said it was impossible to add that to the game. When asked why he said, to paraphrase, "We thought about doing that but we didnt... so the engine doesn't have that feature, so we cannot do it." I was like wtf, seriously? Bailing out of a plane is a game feature, not an engine feature. I know 12-year-old kids who I could give a 3D model of a plane and a pilot who could code a demo of that feature in all but 30 minutes... That's an example of treating players (paying customers) like they're stupid by assuming they're too stupid to see through your lie... Things like that constantly ticked me off until I just couldn't even stomach the game anymore... If I want to play a real combat flight sim and enjoy some actual realism in physics and aircraft performance I fire up IL-2: Cliffs of Dover. If I want a realistic infantry combat experience I fire up ArmA II...
If you're interested in WWII simulations and the prospect of coding them then shoot me a pm. I could help you greatly. For one thing, I have quite a few 3D models I might not mind sharing... everything from a complete, animated Bf-109F4 to a German infantry helmet. I also used to be a very active IL-2 Sturmovik 1946 modder who coded flight models, and have extensive knowledge of flight physics. I'm also a "gun nut" and I collect historical firearms...have lots of reference images, historical data and personal knowledge of how the real weapons operate. And more... My team is currently working on a new engine, but we have a WWII-themed project planned for the future. We have not started development, but we intend to get to it in the next couple of years. It will be yet another highly ambitious project, lol, but we handle that sort pretty well. :-)
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine
Please visit our new forums and help us test them and break the ice!