Doom 3 engine release and game code
-
toneddu2000
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Doom 3 engine release and game code
ok,gotcha, I'll try it.thanks
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: Doom 3 engine release and game code
Someone managed to do it on OSX, so I believe it should be possible.toneddu2000 wrote:Is already possible to compile doom3 under Linux? And if yes, how? Little tutorial for newbiez? t*h*a*n*k*s!
-
toneddu2000
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: Doom 3 engine release and game code
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
Re: Doom 3 engine release and game code
You guys should also take advantage of GL_ARB_depth_clamp.
Re: Doom 3 engine release and game code
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:
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.
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.
- 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.
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];
ENDEngine 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
We knew the words, we knew the score, we knew what we were fighting for
Re: Doom 3 engine release and game code
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.






Productivity is a state of mind.
Re: Doom 3 engine release and game code
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.New Horizon wrote: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.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?
Welcome to i3d, by the way
Re: Doom 3 engine release and game code
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.reckless wrote:without the game does it really matter
Re: Doom 3 engine release and game code
Strange, i tried applying your shader but the game turned pitch black, with just few emmisive showing up.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: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.
- 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.
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.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.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
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.
Re: Doom 3 engine release and game code
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
We knew the words, we knew the score, we knew what we were fighting for
Re: Doom 3 engine release and game code
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
We knew the words, we knew the score, we knew what we were fighting for
Re: Doom 3 engine release and game code
Actually i ment in regards to it being a problem using original doom3 shader content. Sorry for being unclear.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.
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.
Re: Doom 3 engine release and game code
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
Re: Doom 3 engine release and game code
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.reckless wrote:Actually i ment in regards to it being a problem using original doom3 shader content. Sorry for being unclear.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.
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.
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
We knew the words, we knew the score, we knew what we were fighting for