Doom 3 engine release and game code

Discuss programming topics for any language, any source base. If it is programming related but doesn't fit in one of the below categories, it goes here.
Post Reply
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Doom 3 engine release and game code

Post by toneddu2000 »

ok,gotcha, I'll try it.thanks
Meadow Fun!! - my first commercial game, made with FTEQW game engine
ScarT
Posts: 1
Joined: Mon Nov 28, 2011 8:40 am

Re: Doom 3 engine release and game code

Post by ScarT »

toneddu2000 wrote:Is already possible to compile doom3 under Linux? And if yes, how? Little tutorial for newbiez? t*h*a*n*k*s! :)
Someone managed to do it on OSX, so I believe it should be possible.
toneddu2000
Posts: 1395
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: Doom 3 engine release and game code

Post by toneddu2000 »

yeah, I read in the readme that is possible to compile it even on Mac.
Meadow Fun!! - my first commercial game, made with FTEQW game engine
r00k
Posts: 1111
Joined: Sat Nov 13, 2004 10:39 pm

Re: Doom 3 engine release and game code

Post by r00k »

raynorpat
Posts: 27
Joined: Tue Feb 26, 2008 12:21 am
Location: USA
Contact:

Re: Doom 3 engine release and game code

Post by raynorpat »

You guys should also take advantage of GL_ARB_depth_clamp.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Doom 3 engine release and game code

Post by mh »

Pity the shaders are game content (and therefore not under the GPL), there's some useful work you can do with the main interaction shader to improve quality:
  • Drop OPTION ARB_precision_hint_fastest
  • Move the remaining cube map normalization to math.
  • Move some of the per-vertex stuff to per-fragment (there are some normalizations there that could usefully move).
  • Drop the normal map swizzle and get rid of the compression hack, forcing the engine to always load uncompressed normal maps.
That would give you an Ultra+ option for the game which should still run at a fairly solid 60 FPS on reasonably decent modern hardware.

Anyway, here's my replacement interaction shaders with almost everything shifted to the fragment shader (because squares and square roots don't interpolate linearly); it's also got higher color dynamic range on account of not using the color output register from the vertex shader. Bumpmapping and specular lighting are significantly higher quality with this, and everything looks a new level of awesome.

Code: Select all

!!ARBvp1.0
OPTION ARB_position_invariant;

# VPROG_INTERACTION

MOV result.texcoord[0], vertex.attrib[8];
MOV result.texcoord[2], vertex.position; # store position for use in fragment shaders
MOV result.texcoord[3], vertex.attrib[9];
MOV result.texcoord[6], vertex.attrib[10];
MOV result.texcoord[7], vertex.attrib[11];

# generate the vertex color, which can be 1.0, color, or 1.0 - color
MAD result.texcoord[1], vertex.attrib[3], program.env[16], program.env[17];

END


#======================================================================

!!ARBfp1.0

# texture 0 is the cube map
# texture 1 is the per-surface bump map
# texture 2 is the light falloff texture
# texture 3 is the light projection texture
# texture 4 is the per-surface diffuse map
# texture 5 is the per-surface specular map
# texture 6 is the specular lookup table

# env[0] is the diffuse modifier
# env[1] is the specular modifier

TEMP light, color, R0, R1, R2, localNormal, specular, tex0, tex1, tex2, tex3, tex4, tex5, tex6;

PARAM subOne = { -1, -1, -1, -1 };
PARAM scaleTwo = { 2, 2, 2, 2 };
PARAM defaultTexCoord = { 0, 0.5, 0, 1 };

# calculate vector to light in R0
SUB R0, program.env[4], fragment.texcoord[2];

# put into texture space for TEX0
DP3 tex0.x, fragment.texcoord[3], R0;
DP3 tex0.y, fragment.texcoord[6], R0;
DP3 tex0.z, fragment.texcoord[7], R0;

# textures 1 takes the base coordinates by the texture matrix
MOV tex1, defaultTexCoord;
DP4 tex1.x, fragment.texcoord[0], program.env[10];
DP4 tex1.y, fragment.texcoord[0], program.env[11];

# textures 4 takes the base coordinates by the texture matrix
MOV tex4, defaultTexCoord;
DP4 tex4.x, fragment.texcoord[0], program.env[12];
DP4 tex4.y, fragment.texcoord[0], program.env[13];

# textures 5 takes the base coordinates by the texture matrix
MOV tex5, defaultTexCoord;
DP4 tex5.x, fragment.texcoord[0], program.env[14];
DP4 tex5.y, fragment.texcoord[0], program.env[15];

# texture 2 has one texgen
MOV tex2, defaultTexCoord;
DP4 tex2.x, fragment.texcoord[2], program.env[9];

# texture 3 has three texgens
DP4 tex3.x, fragment.texcoord[2], program.env[6];
DP4 tex3.y, fragment.texcoord[2], program.env[7];
DP4 tex3.w, fragment.texcoord[2], program.env[8];

# calculate normalized vector to light in R0
SUB R0, program.env[4], fragment.texcoord[2];
DP3 R1, R0, R0;
RSQ R1, R1.x;
MUL R0, R0, R1.x;

# calculate normalized vector to viewer in R1
SUB R1, program.env[5], fragment.texcoord[2];
DP3 R2, R1, R1;
RSQ R2, R2.x;
MUL R1, R1, R2.x;

# add together to become the half angle vector in object space (non-normalized)
ADD R0, R0, R1;

# put into texture space
DP3 tex6.x, fragment.texcoord[3], R0;
DP3 tex6.y, fragment.texcoord[6], R0;
DP3 tex6.z, fragment.texcoord[7], R0;

# load the specular half angle first, because
# the ATI shader gives a "too many indirections" error
# if this is done right before the texture indirection
# instead of using the normalization cube map, normalize with math
DP3 specular, tex6, tex6;
RSQ specular, specular.x;
MUL specular, specular.x, tex6;
#-----------------


#
# the amount of light contacting the fragment is the
# product of the two light projections and the surface
# bump mapping
#

# perform the diffuse bump mapping
# instead of using the normalization cube map, normalize with math
DP3 light, tex0,tex0;
RSQ light, light.x;
MUL light, light.x, tex0;
#-----------------

TEX localNormal, tex1, texture[1], 2D;
# MOV localNormal.x, localNormal.a # normal map compression hack - is this the only shader they're used in????;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;

# modulate by the light projection
TXP R1, tex3, texture[3], 2D;
MUL light, light, R1;

# modulate by the light falloff
TXP R1, tex2, texture[2], 2D;
MUL light, light, R1;

#
# the light will be modulated by the diffuse and
# specular surface characteristics
#

# modulate by the diffuse map and constant diffuse factor
TEX R1, tex4, texture[4], 2D;
MUL color, R1, program.env[0];

# perform the specular bump mapping
DP3 specular, specular, localNormal;

# perform a dependent table read for the specular falloff
TEX R1, specular, texture[6], 2D;

# modulate by the constant specular factor
MUL R1, R1, program.env[1];

# modulate by the specular map * 2
TEX R2, tex5, texture[5], 2D;
ADD R2, R2, R2;
MAD color, R1, R2, color;


MUL color, light, color;

# modify by the vertex color

MUL result.color, color, fragment.texcoord[1];

END
As a derivative work of id's original it's likely not legally usable under the GPL, so unless anyone can establish otherwise it's probably best to restrict it to personal use.

Engine mods needed include moving your program env parameters 4 to 15 from the vertex program to the fragment program, and removing the normal map texture swizzle from the texture loader. For future work, the light and specular falloff texture lookups could also move to math.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Doom 3 engine release and game code

Post by revelator »

without the game does it really matter :) i been using the gtx gfx mod with doom III for years which adds some more wow for the buck with parralax shaders deform shaders chrome and some general better looks.

Image

Image

Image
Productivity is a state of mind.
goldenboy
Posts: 924
Joined: Fri Sep 05, 2008 11:04 pm
Location: Kiel
Contact:

Re: Doom 3 engine release and game code

Post by goldenboy »

New Horizon wrote:
goldenboy wrote:There are downsides to ripping out stuff that was originally there for a reason.

For example the built-in editor's functionality is much better than standard Radiant. Anyone who makes Doom3 maps is going to use that editor. To be clear, GTK/Netradiant do NOT make the built in editor obsolete. If you rip it out, perhaps consider releasing a standalone Doom3 editor?

And why should people not run Doom3 in 640x480 windowed?
I know quite a few mappers have used our Dark Radiant to build D3 maps rather than D3Edit, but then again Dark Radiant has been heavily rewritten compared to what it was when we started working with the old GTK Radiant source code. It's a completely different beast now.
I'll have to try Dark Radiant for Doom3 mapping sometime soon. Unfortunately netradiant etc. don't have some of the more specific tools such as the lighting editor, GUI editor etc. so I needed to use the built in editor for this stuff.

Welcome to i3d, by the way ;-) your mod is pretty cool.
raynorpat
Posts: 27
Joined: Tue Feb 26, 2008 12:21 am
Location: USA
Contact:

Re: Doom 3 engine release and game code

Post by raynorpat »

reckless wrote:without the game does it really matter
Of course it matters. I know plenty of indie developers who would like more control then either the UDK or Unity gives them, and the D3 gives them everything they could ever ask for. A few Doom 3 mods also have the chance to go standalone.
JasonX
Posts: 422
Joined: Tue Apr 21, 2009 2:08 pm

Re: Doom 3 engine release and game code

Post by JasonX »

mh wrote:Pity the shaders are game content (and therefore not under the GPL), there's some useful work you can do with the main interaction shader to improve quality:
  • Drop OPTION ARB_precision_hint_fastest
  • Move the remaining cube map normalization to math.
  • Move some of the per-vertex stuff to per-fragment (there are some normalizations there that could usefully move).
  • Drop the normal map swizzle and get rid of the compression hack, forcing the engine to always load uncompressed normal maps.
That would give you an Ultra+ option for the game which should still run at a fairly solid 60 FPS on reasonably decent modern hardware.

Anyway, here's my replacement interaction shaders with almost everything shifted to the fragment shader (because squares and square roots don't interpolate linearly); it's also got higher color dynamic range on account of not using the color output register from the vertex shader. Bumpmapping and specular lighting are significantly higher quality with this, and everything looks a new level of awesome.

Code: Select all

!!ARBvp1.0
OPTION ARB_position_invariant;

# VPROG_INTERACTION

MOV result.texcoord[0], vertex.attrib[8];
MOV result.texcoord[2], vertex.position; # store position for use in fragment shaders
MOV result.texcoord[3], vertex.attrib[9];
MOV result.texcoord[6], vertex.attrib[10];
MOV result.texcoord[7], vertex.attrib[11];

# generate the vertex color, which can be 1.0, color, or 1.0 - color
MAD result.texcoord[1], vertex.attrib[3], program.env[16], program.env[17];

END


#======================================================================

!!ARBfp1.0

# texture 0 is the cube map
# texture 1 is the per-surface bump map
# texture 2 is the light falloff texture
# texture 3 is the light projection texture
# texture 4 is the per-surface diffuse map
# texture 5 is the per-surface specular map
# texture 6 is the specular lookup table

# env[0] is the diffuse modifier
# env[1] is the specular modifier

TEMP light, color, R0, R1, R2, localNormal, specular, tex0, tex1, tex2, tex3, tex4, tex5, tex6;

PARAM subOne = { -1, -1, -1, -1 };
PARAM scaleTwo = { 2, 2, 2, 2 };
PARAM defaultTexCoord = { 0, 0.5, 0, 1 };

# calculate vector to light in R0
SUB R0, program.env[4], fragment.texcoord[2];

# put into texture space for TEX0
DP3 tex0.x, fragment.texcoord[3], R0;
DP3 tex0.y, fragment.texcoord[6], R0;
DP3 tex0.z, fragment.texcoord[7], R0;

# textures 1 takes the base coordinates by the texture matrix
MOV tex1, defaultTexCoord;
DP4 tex1.x, fragment.texcoord[0], program.env[10];
DP4 tex1.y, fragment.texcoord[0], program.env[11];

# textures 4 takes the base coordinates by the texture matrix
MOV tex4, defaultTexCoord;
DP4 tex4.x, fragment.texcoord[0], program.env[12];
DP4 tex4.y, fragment.texcoord[0], program.env[13];

# textures 5 takes the base coordinates by the texture matrix
MOV tex5, defaultTexCoord;
DP4 tex5.x, fragment.texcoord[0], program.env[14];
DP4 tex5.y, fragment.texcoord[0], program.env[15];

# texture 2 has one texgen
MOV tex2, defaultTexCoord;
DP4 tex2.x, fragment.texcoord[2], program.env[9];

# texture 3 has three texgens
DP4 tex3.x, fragment.texcoord[2], program.env[6];
DP4 tex3.y, fragment.texcoord[2], program.env[7];
DP4 tex3.w, fragment.texcoord[2], program.env[8];

# calculate normalized vector to light in R0
SUB R0, program.env[4], fragment.texcoord[2];
DP3 R1, R0, R0;
RSQ R1, R1.x;
MUL R0, R0, R1.x;

# calculate normalized vector to viewer in R1
SUB R1, program.env[5], fragment.texcoord[2];
DP3 R2, R1, R1;
RSQ R2, R2.x;
MUL R1, R1, R2.x;

# add together to become the half angle vector in object space (non-normalized)
ADD R0, R0, R1;

# put into texture space
DP3 tex6.x, fragment.texcoord[3], R0;
DP3 tex6.y, fragment.texcoord[6], R0;
DP3 tex6.z, fragment.texcoord[7], R0;

# load the specular half angle first, because
# the ATI shader gives a "too many indirections" error
# if this is done right before the texture indirection
# instead of using the normalization cube map, normalize with math
DP3 specular, tex6, tex6;
RSQ specular, specular.x;
MUL specular, specular.x, tex6;
#-----------------


#
# the amount of light contacting the fragment is the
# product of the two light projections and the surface
# bump mapping
#

# perform the diffuse bump mapping
# instead of using the normalization cube map, normalize with math
DP3 light, tex0,tex0;
RSQ light, light.x;
MUL light, light.x, tex0;
#-----------------

TEX localNormal, tex1, texture[1], 2D;
# MOV localNormal.x, localNormal.a # normal map compression hack - is this the only shader they're used in????;
MAD localNormal, localNormal, scaleTwo, subOne;
DP3 light, light, localNormal;

# modulate by the light projection
TXP R1, tex3, texture[3], 2D;
MUL light, light, R1;

# modulate by the light falloff
TXP R1, tex2, texture[2], 2D;
MUL light, light, R1;

#
# the light will be modulated by the diffuse and
# specular surface characteristics
#

# modulate by the diffuse map and constant diffuse factor
TEX R1, tex4, texture[4], 2D;
MUL color, R1, program.env[0];

# perform the specular bump mapping
DP3 specular, specular, localNormal;

# perform a dependent table read for the specular falloff
TEX R1, specular, texture[6], 2D;

# modulate by the constant specular factor
MUL R1, R1, program.env[1];

# modulate by the specular map * 2
TEX R2, tex5, texture[5], 2D;
ADD R2, R2, R2;
MAD color, R1, R2, color;


MUL color, light, color;

# modify by the vertex color

MUL result.color, color, fragment.texcoord[1];

END
As a derivative work of id's original it's likely not legally usable under the GPL, so unless anyone can establish otherwise it's probably best to restrict it to personal use.

Engine mods needed include moving your program env parameters 4 to 15 from the vertex program to the fragment program, and removing the normal map texture swizzle from the texture loader. For future work, the light and specular falloff texture lookups could also move to math.
Strange, i tried applying your shader but the game turned pitch black, with just few emmisive showing up.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Doom 3 engine release and game code

Post by mh »

Did you also make the engine mods I mentioned?
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Doom 3 engine release and game code

Post by mh »

Interestingly, the interaction algorithms from the NV20 and R200 paths could be legally ported, modified, etc, as everything is there hard-coded in the engine. That seems more like a viable baseline to work from for this kind of thing, backs up my original suspicion that Doom 3's renderer is actually hard-coded in nature and intention (if not in fact so far as the ARB2 path is concerned), and is worth pursuing.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
revelator
Posts: 2621
Joined: Thu Jan 24, 2008 12:04 pm
Location: inside tha debugger

Re: Doom 3 engine release and game code

Post by revelator »

Of course it matters. I know plenty of indie developers who would like more control then either the UDK or Unity gives them, and the D3 gives them everything they could ever ask for. A few Doom 3 mods also have the chance to go standalone.
Actually i ment in regards to it being a problem using original doom3 shader content. Sorry for being unclear.
Tbh im not sure if the modders who only had the sdk to work with used any of the original shader content so its guesswork,
if they did i guess ID would have shot them down long ago.
Productivity is a state of mind.
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: Doom 3 engine release and game code

Post by leileilol »

There's a potential problem regarding specific usage rights from the SDK's eula i believe. At least Quake 3 had that problem, some mods that did go standalone that were based on the Quake 3 SDK's code had expressed ignorance to it, most famously Urban Terror
i should not be here
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Doom 3 engine release and game code

Post by mh »

reckless wrote:
Of course it matters. I know plenty of indie developers who would like more control then either the UDK or Unity gives them, and the D3 gives them everything they could ever ask for. A few Doom 3 mods also have the chance to go standalone.
Actually i ment in regards to it being a problem using original doom3 shader content. Sorry for being unclear.
Tbh im not sure if the modders who only had the sdk to work with used any of the original shader content so its guesswork,
if they did i guess ID would have shot them down long ago.
Ultimately none of that matters. Copyrighted material is under copyright until it expires or is explicitly relinquished, and the shaders, being game content, are not GPL. id may make a decision to not go after you now, but that doesn't mean that you're safe in perpetuity.

I think an early project of value would be to create a replacement ARB asm light interaction shader from the GPL code in draw_nv20 and draw_r200. That would enable anyone who wants to pursue a higher quality (or even lower quality as a tradeoff against performance) option to do so legally.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
Post Reply