Wimpier shader support

Feb 21, 2009 at 10:20 AM
Edited Feb 21, 2009 at 10:29 AM
I've got an old graphics card; it reports that it supports pixel shaders up to version 1.4 and vertex shaders up to version 1.1.  Right now, this library crashes when I try to draw (left a comment on the tutorial).

Is there any way it could degrade more gracefully when shaders aren't supported?  I don't need anything fancy, I mean, it seems like this should ideally run on any hardware that could run Quake 3.

I can make it stop crashing if I go into basicQ3Effect.fx and fuss with the techniques, commenting stuff out or telling it that it's version 1.0.  The graphics even look kind of okay--except that the brick walls are all smeared out instead of repeating, while the floor and sky are fine.  (Change vs_2_0 to vs_1_0 and ps_2_0 to ps_1_0 to see what I mean.)  I don't know enough about pixel shaders to make a lower quality version, but I'm hoping you could help.

Also, when I was first lacking the ability to render through the library, I was hoping I could just access the map data directly through the Q3BSPLevel class since you have written a great parser...  But it's all private; is there any particular reason for that?

Thanks!
Developer
Feb 22, 2009 at 5:30 PM
I didn't even know basicQ3effect was compiled versus 2.0. Looking through the code I can't see any reason why it shouldn't be switched to 1.1. Just change the code on the two techniques to vs_1_1 and ps_1_1. Doing that didn't show any difference in the bricks on my machine.

The only other problem you might have with shaders is if they use lots of stages. Quake 3 used a fixed-function pipeline and they could get away with some things that just won't fit into ps_1_1. There aren't a whole lot of effects that need more than four stages, anyway.

As for the private members that's just because I didn't think they would be useful to anyone. What would you like exposed?
Feb 22, 2009 at 10:24 PM
Edited Feb 22, 2009 at 11:34 PM
I beg you to bear with me as I'm very new to the Q3 map format, and very new to dealing with shaders... :)

Is it possible to use a pipeline like Quake 3's, or is that just flat unreasonable?  Here's what the walls look like on my machine, when I change to _1_1:  http://img156.imageshack.us/my.php?image=stretch.png  This happens because in version 1.x, the uv coordinates are clamped to 0..1.  If you don't see that even when compiling for > 1.x, then it's very weird.  Right now I'm looking to see if I can find a solution...

Tried adding these lines to the sampler_states but with no luck:
    addressU = WRAP;
    addressV = WRAP;

The fact that it draws the FLOOR fine makes no sense to me at all.  EDIT:  For some reason it fails to tile any texture that is NOT a power of 2.  The floor is 256x256, the wall is 384x384.  I don't know why this is an issue, but...well, at least there's a solution...

Also, I've seen these lines of code in other projects' initialization, they make it throw a sane error when you start up the project, instead of chucking an exception later on, and you might want them for code that is compiled for 2.0+:
            graphics.MinimumVertexShaderProfile = ShaderProfile.VS_2_0;
            graphics.MinimumPixelShaderProfile = ShaderProfile.PS_2_0;

As for the private members...  There's a lot of things someone might want to do with the map data.  As a really simple example, Quake 3 maps store a list of entities in the map like players, monsters, etc...  It's very useful to store that stuff in the same place as the map, and without public access, I need a separate file to encode where the stuff in my map is!

For something more complex:  Games like this often allow certain brushes to move.  Lifting platforms, etc.  Also, often brushes have other effects, like an un-drawn one that says "The player can collide with this" or "this is a jump platform", or a drawn one that says "the player can't collide with this".  Don't know how much arbitrary metadata there is in the Quake 3 format, but being able to manipulate brushes and do some custom collision detection would be great.  (I think lots of people would want to do custom collision detection anyway!)

To make it even weirder...  One thing my project wants to do is to draw dynamic textures on walls, and that needs some access to the internals so I can change their textures (or at least tell them where to retrieve the current texture).  I'm going to do that with other meshes instead of the map, for now, but it would be nice in the future.  Also, in the future I'd like to try and do some weird portal stuff...for example, I would really like to load multiple maps at a time, and connect them arbitrarily, like say "this surface actually goes to that map over there".  And while I don't know how skybox stuff works here yet, that's something I want to do a lot of custom stuff for.  This last paragraph is mostly pie-in-the-sky stuff, the previous ones are far more useful to me.

Just keep in mind that your project is, what, the only XNA library ANYWHERE that can import a commonly-used map format?  I suspect a lot of people would really like to build some advanced stuff on it.  I can probably hack up the library to do what I'd like, but support out-of-the-box for things like games that want to access entities and screw with brushes would be awesome. In my case, I'm hoping to use this as part of a core engine for a five-week game competition.  Even if I have to change a ton of stuff, it's already a huge time-saver!  Thanks!