Doom 3 engine release and game code

It's out now.

https://github.com/TTimo/doom3.gpl

*SNAGS REPOSITORY AS ZIP ASAP!!!

Anyone able to compile this? I don't have VS 2010, just 6.

Someone port this to VC6.

Got it.

Gonna try a quick compile before bedtime.

Interesting. Seems the editor uses MFC which won't work with Express. And, since the editor is integrated into the engine, it means that some surgery is required.

Alternately I could just grab a set of MFC headers and libs from work...

Man, the scripting language code (compiler and execution) looks familiar.......

*SNAGS REPOSITORY AS ZIP ASAP!!!

Anyone able to compile this? I don't have VS 2010, just 6.

Someone port this to VC6.

i downloaded the 2010 pro trial and its still compiling....

OH YEAH! 4 succeeded 1 failed and 3 warnings, but the win32 exe compiled!


Welp this is what i get when I run it, wrong game API version.

@r00k: needs the 1.3.1 patch

unfortunately it also seems the typelib exe is hardcoded to look for the doom folder on the root of the hard drive to generate headers from the scripts, kinda like how qbsp is hardcoded to look for the quake folder off the root of the hard drive.

Just got a clean compile (aside from a load of precompiled header warnings that I'm gonna ignore for now). Using 2010 Pro SP1, June 2010 DXSDK.

It seems as though the TypeLib project is not needed for building, so you can remove that from your Solution Explorer.

Next step is to try removing the editor and other tools code from the engine. Aside from bloating the executable (no big deal in the days of 4GB+ RAM machines IMO) the use of MFC shuts out Express users, and so it must die.

I'd love to follow your progress through commits on Github (or else).

I'd love to follow your progress through commits on Github (or else).

I may do a public SVN as soon as I get a decent baseline to start working more seriously from.

Current objectives look something like this:

• Remove tools/etc from source to eliminate MFC dependency.
• Port project to MSVC 2008 Express.
• Remove alternate rendering backends - ARB2 only baby!
• Try to do something about map load times. DDS only all the way? Get rid of BGR->RGB swap for TGAs? Something else?

Beyond that I'm vague. A D3D port is a longer term objective, and I think - despite the fact that the engine uses shaders in game content - I can get away with it, as the renderer is really based around fixed func requirements, and light interaction appears to be the only shader-based stuff in it. Alternately I may write an ARB asm to HLSL converter (I've had a slight itch to do something like that for a while).

Cute fact. The original code name for the Q3A engine was Trinity. Doom 3 is Neo. What betting that Rage is Morpheus?

Update: it runs clean too.

Cute fact. The original code name for the Q3A engine was Trinity. Doom 3 is Neo. What betting that Rage is Morpheus?

Since Trinity's name for Q3 was coined in 9th of August, 1997.... the Neo connection was probably a joke then he stuck with it. like Valve and "Source" (HAHAHA SOURCE ENGINE HAHAHAAHAHAH DUMBEST NAME EVER)


There's still tr_ (Trinity) prefixes in Doom3 code, as a shock to me the engine is derivative (!)

Got a pleasant surprise that the skybox to cubemap conversion code I put into both RMQ and DirectQ is more or less identical to that in Doom 3.

There's a nice looking MMX memcpy in there that might be useful.

According to the readme the Carmack's Reverse code was disabled, so it won't work. However, the readme doesn't mention whether they also removed it, so it may be hidden in there somewhere.

It's interesting to think that if the code is there, any derivative engines that re-enables it may be infringing Creative's patent.

By the way, the only thing I'd really like to have in this engine is an efficient relief mapping implementation. There's a mod that does it, but it runs awfully slow. I wonder how fast an updated renderer could get it working.

According to the readme the Carmack's Reverse code was disabled, so it won't work. However, the readme doesn't mention whether they also removed it, so it may be hidden in there somewhere.

It's interesting to think that if the code is there, any derivative engines that re-enables it may be infringing Creative's patent.

The code for Carmack's Reverse is not in this at all, that's the whole point. If it was then they'd still be going against Creative's patent. From my understand Carmack has replaced it with a less speedy technique.