Bug list

Coordinator
Oct 6, 2007 at 2:13 AM
Use this thread to list any bugs you may find. Please list engine version, and issue in as much detail as is needed. If needed we may set it as an issue to be fixed on newer versions.

Thank you,
Nic
Oct 6, 2007 at 3:34 AM
Edited Oct 6, 2007 at 3:46 AM
Finally got a chance to look at the code tonight. Unfortunately, the terrain drawing code in 0.17 does not work on nVidia 8800 GTX - ForceWare 163.69 (Vista 64).

The error is triggered in QuadTree.cs, line 330:
Terrain.Device.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, Width * Height, 0, (Width - 1) * (Height - 1) * 2);

EDIT: After further review, most of the draw calls are affected. Have you made any changes to the shader input/output semantics recently that would trigger this inconsistency?

It appears as though the shader used to render the terrain is expecting a vertex format other than what is supplied. I'll take a look at it, but I wanted to let you know, since its probably a lot easier for you to fix as you know the code much better than I. This failure is propagating as an unhandled exception. The exact DirectX debug output is:

(Ignore the links, these CodePlex forums are lame :) )

156 Direct3D9: (WARN) :SetVertexDeclaration: NULL declaration pointer
156
156 Direct3D9: (INFO) :Using FF to VS converter
156
156 Direct3D9: (INFO) :Using FF to PS converter
156
156 Direct3D9: (ERROR) :Vertex shader function usage (D3DDECLUSAGE_BINORMAL,0) does not have corresponding usage in the current vertex declaration
156
156 Direct3D9: (INFO) :The vertex declaration is (Stream, Offset, Type, Method, Usage, UsageIndex):
156
156 Direct3D9: (INFO) :0, 0, D3DDECLTYPEFLOAT3, D3DDECLMETHODDEFAULT, D3DDECLUSAGE_POSITION, 0
156
156 Direct3D9: (INFO) :0, 12, D3DDECLTYPEFLOAT3, D3DDECLMETHODDEFAULT, D3DDECLUSAGE_NORMAL, 0
156
156 Direct3D9: (INFO) :0, 24, D3DDECLTYPEFLOAT3, D3DDECLMETHODDEFAULT, D3DDECLUSAGE_COLOR, 0
156
156 Direct3D9: (ERROR) :DrawIndexedPrimitive failed.
156 Direct3D9: (WARN) :SetVertexDeclaration: NULL declaration pointer
156
156 Direct3D9: (INFO) :Using FF to VS converter
156
156 Direct3D9: (INFO) :Using FF to PS converter
156
156 Direct3D9: (ERROR) :Vertex shader function usage (D3DDECLUSAGE_BINORMAL,0) does not have corresponding usage in the current vertex declaration
156
156 Direct3D9: (INFO) :The vertex declaration is (Stream, Offset, Type, Method, Usage, UsageIndex):
156
156 Direct3D9: (INFO) :0, 0, D3DDECLTYPEFLOAT3, D3DDECLMETHODDEFAULT, D3DDECLUSAGE_POSITION, 0
156
156 Direct3D9: (INFO) :0, 12, D3DDECLTYPEFLOAT3, D3DDECLMETHODDEFAULT, D3DDECLUSAGE_NORMAL, 0
156
156 Direct3D9: (INFO) :0, 24, D3DDECLTYPEFLOAT3, D3DDECLMETHODDEFAULT, D3DDECLUSAGE_COLOR, 0
156
156 Direct3D9: (ERROR) :DrawIndexedPrimitive failed.


I wonder if this is related to your post on the XNA boards about the terrain rendering error for one of the users.
Coordinator
Oct 6, 2007 at 6:12 AM
Well I am having terrain issues on my Radeon 9800se, which is a much older card. The issue seems to be with the index buffer, which could also be related to the vertex type.

I'll take a look at it, if you would like to as well, the custom vertex type is in Terrain.cs, near the very top of the file, it is called VertexTerrain.
Coordinator
Oct 6, 2007 at 7:00 AM
The custom vertex doesn't have a Binormal element in it. Which is something I didn't know if I needed or not. The normal mapping 'seems' to work fine on my NVidia 7900gs go 256mb. If you watch the video preview you can see it. Although I have had some issues with bumpmapping when using spritebatch or the 3d particle systems and water together. Not sure if they're related or not.
Oct 6, 2007 at 3:20 PM
I am really not understanding how you have your shaders set up. In both the terrain and water FX files, none of the techniques have a vertex input format that match what is being provided. For instance, for terrain, you are providing Position, Normal, and 24-bit Color (as COLOR0). Yet, in the terrain shader techniques, the input formats are:

POSITION, NORMAL, TEXCOORD0 (4-component)
POSITION, TEXCOORD3 (why not 0?), NORMAL, COLOR0
or
POSITION0, TEXCOORD0, NORMAL0, BINORMAL0, TANGENT0, COLOR0

The first one is close to matching, but its still off by semantic name (TEXCOORD instead of COLOR), and type size (Vector4 vs Vector3).

Does the 0.17 version have mismatched code files? It looks almost like a new version of Terrain.cs/Water.cs and old shaders, or vice versa....
Coordinator
Oct 6, 2007 at 4:19 PM
I've only been working with shaders a little over a month, so I can believe they aren't made properly. All I knew was they were working fine (on my computer). Obviously this isn't the case with all cards.

The first two techniques are old and aren't currently being used.

The last techinque, MultiTexturedNormaled, is the one I've been using for the terrain. I'm not sure why it worked on my computer if it wasn't receiving the right information. I'll see what I can do, I've got finals this week, and work every day.
Oct 6, 2007 at 5:06 PM
No worries, as long as I know that these are really the right versions of the files, I can work on correcting them. I'll just populate the binormal/tangent data with zero vectors for now, and fix up the texture-coord references. In all honesty, I'm not really sure how bump-mapping was actually working... ;)

This is an interesting problem, indeed. It appears the GeForce 8-series drivers refuse to work with mismatched vertex formats (which I guess should be expected), while the 7-series drivers are able to recover somewhat, at least to the point where they can fix up position information.


Also, I'm not sure if you've read my other post here, but what are your plans as far as overall engine structure/architecture? If you're serious about extending the existing code-base into a game engine, it's probably going to be a good idea to spend some time on design. Especially once people start building the physics, AI, GUI, and gameplay components, it'll be very convenient to know how everything is supposed to fit together instead of just guessing.


Anyway, good luck on your exams!


Oct 6, 2007 at 5:45 PM
I updated the vertex formats used in Terrain.cs and Water.cs. Most of the fields aren't being populated, like Normal/Binormal/Tangent, and the texture coordinates for reflection/refraction maps, but at least the shader input structures match what's being provided now.
Coordinator
Oct 6, 2007 at 7:21 PM
Edited Oct 6, 2007 at 8:19 PM
That is awesome, thank you shaw. I will do what I can to help in the next week when I get the chance.

As far as engine structure, absolutely we should go over design. I was thinking about using doxygen, or at a minimum setting up some uml diagrams through visio. Doxygen is free I believe, so is Posideon (sp?), those might be a better way to go.

I will start a thread on engine structure.

I would like to keep modularity at a very least, after that the goal would likely just need to be ease of use, power/efficiency, and features. Although I started the project, by putting it on here I accept that it is completely open to change. My goal is simple an easy to use 3d engine, that is free and open source for the XNA community to use, if that means complete re-writes of specific parts then so be it. :)

If you find a solution to the terrain rendering it would great if you could post an update.

It is a shame we're running into graphical issues, I was really hoping to get someone for graphics on here to work on that, I focused on A.I. mostly during school and would like to get some player/bot classes going. It is cool you're helping with graphics but I know you're hoping to do physics, so it would be nice somebody interested in the graphics aspect of it, especially since it is the largest draw of an engine.
Coordinator
Oct 8, 2007 at 7:22 AM
Shaw, just so you know, your updated version is not normal mapped on my computer. I realize it is using zeroed values for binormal and tangent, so it really shouldn't work anyway, but I thought it'd be good to know that zeroing out did change the effect on my video card. Seems there are some values in those fields, at least my video card thinks so....
Oct 8, 2007 at 3:30 PM
Edited Oct 8, 2007 at 3:30 PM
I can only think of two possibilities:

  1. Your video card is reading over into bad memory, which gives the impression of seemingly reasonable tangent/binormal vectors, though I would think this would cause corruption of the position data as the vertex stride would be wrong.
  2. The GeForce 7-series drivers are able to detect the discrepency and calculate binormal and tangent data based on the texture coords and vertex normals. However, I find this very hard to believe.

I would like to see the DirectX debug output when you run the original code, it may be insightful.
Coordinator
Oct 9, 2007 at 5:31 AM
When I get a change I'll d/l that program you sent me a link to so I can use DX debug in C# express. I'm not able to run in the full Visual studio for XNA until 2.0 right?
Oct 9, 2007 at 6:31 AM
XNA 1.0 works just fine in Visual Studio Pro, you just don't get content pipeline integration and xbox deployment. Whenever I use XNA, I use Visual Studio Pro and build the content manually.
Coordinator
Oct 9, 2007 at 7:02 AM
Never really tried it, figured I'd wait for 2.0...

Would it be easier to build manually or download the software for C# express to allow DX debugs?
Oct 9, 2007 at 3:36 PM
If all you need is DX debug output, its probably not worth using Visual Studio Pro. I use it because the debugger is much better and provides more information at run-time. The DebugView program is small and very easy to use, so unless you need other features of Visual Studio Pro, it's probably not worth messing with it.