Zoomastigophora

Just nuke support for cards that old - you have to draw the line somewhere. This game has been in development so long that you've actually lived through a major technological shift in GPU hardware architecture and corresponding APIs, meaning that many of the old requirements/assumptions are no longer valid. Maintaining a legacy codebase for an increasingly diminishing audience will just burn out existing developers and turn away potential new developers that don't want to be saddled with that much legacy baggage. Plus, as the team has clearly become aware of, maintaining that degree of legacy support virtually guarantees your game will look like something from the early 2000s. As long as you maintain a forward rendered render path for older/weaker GPUs (e.g. first generation SM3 cards and older), you should still be able to cover a large audience and not make your graphics engineers want to kill themselves. Plus if this goes through, I'd be interested to see if I can contribute again, especially if myconid is serious about implementing a deferred render path of some sort as building a rendering system from scratch has been a personal goal of mine for a while.

Ok. I'll just need to remember that the struct is misleading then.

I was actually looking at: CVector3D CMatrix3D::GetTranslation() const { CVector3D Temp; Temp.X = _14; Temp.Y = _24; Temp.Z = _34; return Temp; } and //Applies a translation to the matrix void CMatrix3D::Translate(float x, float y, float z) { _14 += x; _24 += y; _34 += z; } and this in the header // concatenate given translation onto this matrix. Assumes the current // matrix is an affine transformation (i.e. the bottom row is [0,0,0,1]) // as an optimisation. void Translate(float x, float y, float z); void Translate(const CVector3D& vector); SetTranslation is storing the translation as the 4th row, it just looks like the 4th column because the entries are laid out transposed of the struct. I think that CMatrix should be redone so that it does everything column-major consistently and if that breaks stuff, we'll fix it. I don't think it actually will break much since most usage of CMatrix assumes everything is handled column-major. (The SSE asm matrix multiply was just something I wanted to do for my own personal amusement. It's how this whole brainhurt of convention inconsistency began. Once the renderer becomes more feature complete, it'll probably be a good idea to go through with a profiler and see what operations would benefit being done in optimized asm.)

Oh god, I think I know where the confusion is coming from. The matrix is actually constructed as row vectors, but since OpenGL uses column-major notation, all the operations are adapted to allow column-major convention. For instance, with column-major matrices, vector-matrix multiplication would have the matrix on the left of the vector, but since CMatrix3D is row-major, doing so would give the wrong result so the operator transposes the calculations (and also why *= flips the order around). I'm pretty sure this is the case since translation should be the 4th column if the matrix was column-major, but it's stored in the 4th row in CMatrix3D, which would be the case in row-major. Edit: Wait, after reading more usages of CMatrix, I'm even more confused. In some cases, things seem to be stored column-major, others as row major. I don't even... In any case, OpenGL doesn't seem to actually care which order the matrix is constructed in as long as its located in a contiguous block of memory. If the matrix was constructed using row vectors, you can use glLoadTransposeMatrix(). This will make writing that SSE asm matrix multiply even more confusing...

From my reading, (_11, _12, _13, _14) would be the first column, unless that struct definition is setup so that columns read left to right instead of top to bottom, but this comment would seem to indicate otherwise: // (Be aware that m(0,2) == _data2d[2][0] == _13, etc. This is to be considered a feature.) In which case, * is multiplying the first column vector of A with the first row vector of B, when it should be the other way around.

But then where's the fun in that? Also, unless players are playing 0 A.D exclusively, it's a bad idea (I think) to have them set AA/AF in control panel because that forces it on for all games. Probably less of a problem for nVidia users that can setup profiles for individual games, but it would be a total pain in the @#$% for ATI users like me .

I might go ahead and redo the * and *= operators so that they're defined in the conventional manner and see what breaks. I'm probably going to be doing more work in the graphics code later and it'd be nice to not have to worry about multiplication weirdness.

Thanks for the reply, but I wasn't asking about the algebra of matrices. Maybe my phrasing was unclear. From what I've done in linear algebra and what I've seen with most math and computer graphics related work using matrix multiplication, it's defined as C = A x B where C[i,j] = sum(A[i, 1:n] x transpose(B[1:m, j])), the same definition Wikipedia gives. The implementation in CMatrix3D instead gives C[i,j] = sum(B[i, 1:n] x transpose(A[1:m, j])) and I was wondering if that was intentional because it's unconventional for matrix multiplication to be defined like that. Also, what's a sound guy doing with a theoretical background in abstract mathematics? . I haven't thought of fields, rings, and groups since Category Theory and Number Theory in high school.

I'm confused by the matrix multiplication implementation; as it is now, A * B is mathematically B * A, which seems incredibly counterintuitive and prone to errors (at least to me). Was there a reason for it to be implemented as a right multiply?

Do we even have per-pixel lighting? It seem like it's all being done per-vertex, except the water system.

The wiki has some high level conceptual stuff on the organization of the engine, which can help orient you, but otherwise, best you can do is read the code and read the comments (or generate the cpp-doc/look at the cpp-doc on Trac). I find Visual Studio's caller graph and class diagram generation abilities immensely helpful when trying to figure out how thing's are interacting.

Don't know, but after rebuilding FColladaD on my machine, they are both loading properly and remaining loaded now. I had to comment out this line in DLLEntry.cpp to get it to compile: case DLL_PROCESS_VERIFIER: It was telling me DLL_PROCESS_VERIFIER was undeclared, which was weird since that looks like a Win32 thing. Maybe it's been removed now in Windows 7.

Yup, that fixed it. Maybe there's something wrong with the debug compiled build of FCollada?

Just in case you hadn't seen, I've added a patch to that ticket.

No luck, it's still loading and unloading the DLLs. Is there anything that changes between the Release and Debug modes that could be causing this?