Doom 3 engine release and game code

[revelator]

Slowly updating Vanilla with bfg stuff, so far i updated idlib with the newer one from bfg + some of the renderer mainly the matrix functions which uses SSE in bfg.
So far nothing earthshattering performance wise but it does seem to make Things even more detailed.

[motorsep]

I think you are doing it wrong You could simply fix several things in the BFG engine, which is much easier than backporting 2012 engine into 2004 engine.

As far as performance, check my videos: http://www.youtube.com/playlist?list=PL ... l-eh3F4C2n

[revelator]

Tbh its mostly because i dislike bfg's mod support and who knows it might turn out quite well when i get the cg/glsl renderer ported.

[motorsep]

[revelator]

I know but i newer liked compiled resources and Theres no way around that with bfg no matter the port. And i like to keep compatibility with the older engine to the max extent possible.
I actually put a lot of thought into this and it seems most agree with keeping the old engine and updating parts of it with the bfg code. It will be hard, it might not turn out well but thats what we do .

Darkplaces turned out quite well following a route most would newer have belived possible for such an old codebase .

Im not reinventing the Wheel just grabbing bits and pieces from bfg that are more up to date with modern hardware to make a nice easygoing Little cleansource with good performance for developers to toy with.

[revelator]

Heh something strange turned up while removing the last bits and pieces of the editor interface i seem to have uncovered a bug in idlib removing the defunct editor callers cauused the game to crash
stating it was unable to read memory in idlibs

ID_INLINE idStr operator+(const idStr &a, const idStr &b)
{
idStr result(a); // cannot read memory
result.Append(b);
return result;
}

debugging further brought me as far as the error being generated somewhere in the savegame system but im a c++ novice so i couldnt put a pin in it yet.
Rather funny that it showed up after removing unused code though

[motorsep]

Or maybe it was used? I asked idSoftware if they care to release tools for BFG, they said not at this time. So it sounds like there were tools in the engine, but got safely removed. So maybe what you trying to remove intertwined with the game code?

Btw, idLib has precision loss with SSE (old idLib didn't have SSE in 32bit and thus didn't have the issue), as player can get stuck in the mesh level / terrain, even with 32bit binaries. Care to fix that issue?

[revelator]

Checked the functions before removing and they where not reference anywhere only call they made was unhooking the screen when an editor was running but all the editors where removed from this source by mh. Btw this is not BFG its Vanilla .

hmm so far i havent had any problems with getting stuck but ill look out if it happens.

[motorsep]

Collisions would be Pluecker's coordinates math, I think it hangs on rotations.

[revelator]

Hmm havent touched plueckers code yet maybe something that snuck in with id's updating the code ? ill check it out.

[revelator]

I played a bit with the patch to add multiprocessor support to doom3 and it seems to be pretty straight forward to port for msvc but it crashes when allocating mutexes in R_FrameAlloc.

If i disable that part it actually runs and the omp pragmas seem to Work with msvc 2012 so it might be a small change thats needed for msvc, so if anyone can get it running id love to hear

[revelator]

Ugh was a missing init :S it runs now but the modified shadow code is still not working, has the same bugs as some code posted by a member of doom3world all models go Black so i left out that part.

the omp factors are pretty simple, just yank this in precompiled.h

after #include <Windows.h>

#include <omp.h> // for threading

typedef omp_lock_t semaphore_t;
#define SEM_INIT(mutex_addr) omp_init_lock(mutex_addr);
#define SEM_WAIT(mutex_addr) while (!omp_test_lock(mutex_addr))
#define SEM_POST(mutex_addr) omp_unset_lock(mutex_addr)

for each mutex you need to call SEM_INIT
SEM_WAIT tests and hooks it into the omp threading function.
SEM_POST runs those threads if SEM_WAIT was succesfull and also unsets the threading.

Since my code is pretty far from the standard doom3 code now a patch would be impossible for me to make so it will be a by hand project if anyone want to try it out.

[anonreclaimer]

[motorsep]

I'd also like to see results of the performance test - can your work beat Doom 3 BFG in performance? (I highly doubt that)

[revelator]

would be a little hard to compare gfx wise since Vanilla is capped at 60 fps while bfg can do 120 especially since my rig is allready running it at what its capable of hehe.
But if someone with a more modest PC will do a comparison im also all ears.

Bear in mind though that the shadow volume improvements this Fellow made has not made it in since i cannot get them to run correctly, and i suspect they have a quite huge impact on performance
cause shadow volumes are really nasty performance wise.

Atleast for MSVC users my port provides a basic framework for multithreading Vanilla, for mingw the changes needed would more or less just be the inclusion of pthreads + libgomp.