Jump to content
The Dark Mod Forums

TDM Engine Development Page


zergrush

Recommended Posts

Revelator provided the following insight for possible windows side issues with LLVM:

 

http://llvm.org/builds/

 

these hook into msvc2010 through 2013 so you can use clang with msvc.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Yeah, I saw that the latest LLVM had implemented some Windows/MSVC compatibility features. Definitely very useful for static analysis of the codebase. However, that's quite different to the earlier LLVM discussion where we'd likely end up replacing the current idCompiler/idLexer/idParser with a LLVM front-end and a suitable back-end.

  • Like 1

I am the bat. The night is mine.

Link to comment
Share on other sites

I created a tracker on our end (3793).

 

Yeah, the way revelator was discussing this it almost sounded like he wanted to run the entire codebase inside LLVM???

 

Edit: Yep, that's what he was thinking

 

 

LLVM + clang could also be a nice compiler for Doom3.

 

 

I'm not qualified to agree or disagree... :P

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

That's not really "running the entire codebase inside LLVM". clang is a C & C++ front-end for LLVM, which is just a compiler infrastructure. Using clang doesn't mean that your code runs inside a VM as the "VM" in LLVM might suggest. The resulting object files and executables are normal Windows / Linux / Mac executables, just like if MSVC or GCC was used as the compiler (although, the generated assembly code will likely be different due to different optimisations etc.)

 

The benefit that clang brings is pretty hardcore code analysis and warnings. From what I've seen, performance of the resulting bin can be lower (or higher) than GCC depending on the nature of the code, so we'd have to evaluate that in the TDM case. clang also tends to compile much faster, so you don't sit around waiting for builds quite as long if you are making lots of small modifications followed by a new build each time.

I am the bat. The night is mine.

Link to comment
Share on other sites

Thanks for the clarification. Seems that revelator is having trouble compiling his build with clang due to some of the ATL code in the tools portion.

Yeah, quicker compiles and better code analysis sound like some nice benefits.

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

  • 3 weeks later...

Revelator is still plugging away. He's now ported entity sorting from BFG:

 

http://forums.inside...t=5476&start=30

 

https://github.com/revelator/Revelation

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I believe it's similar to what he's ported for light rendering where larger lights are drawn first to avoid pipeline stalls.

It seems that he's preparing to port BFG's rendermatrix code which I believe would include GPU skinning.

Regardless, his work is just making it easier for "someone" to port the remainder of BFG's renderer.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Seems the most fitting place to post, so I'm just asking. Does anyone has the possibility to contact sikkpin or relevator? They both seem to be pretty informed about how the engine, especially the graphical side, works, and I could need some help. :)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

revelator joined the here... he's not replying to PM's?

 

http://forums.thedarkmod.com/user/34386-revelator/

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

No luck reaching rebb?

He answered, but I thought it would be helpful having some guys in the boat who worked on that side recently.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I would also suggest you visit:

 

http://forum.beyond3d.com/forumdisplay.php?f=22

 

and open a thread about any questions you have.

 

Also, if you haven't already studied this, Humus has an excellent selection of OpenGL demos:

 

http://www.humus.name/index.php?page=3D

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I lieu of waiting for LATC or RGTC compression to arrive, I wonder if using MH's new normal-map shader would allow

the use of standard DXT5 normal-maps without the typical garbage quality in Doom 3:

 

https://web.archive.org/web/20111203210912/http://mhquake.blogspot.com/2011/11/doom-3-shaders.html

 

?

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Can the shader be downloaded somewhere? It's pretty useless if he is just talking about it ;)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Here it is, page 7:

 

http://forums.inside...start=90#p40692

 

 

 

!!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

 

 

 

Edit. Bad assumptions, he's removed DXT5 compression completely :(

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Thanks.

 

Will compare both, but I know ours is much longer.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Yeah, it might still be worthwhile to do some of the math based normalizations.

 

That said, I am also wondering if DXT5 encoding techniques have improved since we last tested normal-map compression.

I've been trying to find references but the only thing I found was some hack about using Alpha and Green only which would

not work without substantial changes to the input mechanism anyway.

 

Time to PM MoroseTroll and see if he can help?

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Possibly better RXGB normal map compression: https://github.com/paulvortex/RwgTex ?

 

Example enhancement:

 

super2x (scale 4x with backscale to 2x using lanczos filter)

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

So I've been thinking on the current problems with Sikkpin's SSAO implementation.

 

I think the best option would be:

 

1) Identify each ambient light volume in a scene

2) Capture a low resolution depth-buffer render of all geometry owned by each ambient light volume excluding alpha surfaces (bounded by PVS)

 

(Sikkpin comment:

 

There's already a function to capture the depth buffer to a texture, "CopyDepthbuffer(...)". You just need to add an idImage to call it. See "RB_STD_DrawView()" in my source. After the depth buffer is filled (with RB_STD_FillDepthBuffer( drawSurfs, numDrawSurfs );), I capture it. Right now, I only use it for things like soft water/particles and some other basic depth effects. Doing ssao or dof with it will be tricky because you'll have to linearize it which, because of the infinite far z that this engine uses, is not so simple.

)

 

3) Feed this image to each ambient light pass for the scene and use it for an AO term in the Ambient shader

 

This should allow SSAO without artifacts on skybox and alpha surfaces with the least amount of render work.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
    • Ansome

      Well then, it's been about a week since I released my first FM and I must say that I was very pleasantly surprised by its reception. I had expected half as much interest in my short little FM as I received and even less when it came to positive feedback, but I am glad that the aspects of my mission that I put the most heart into were often the most appreciated. It was also delightful to read plenty of honest criticism and helpful feedback, as I've already been given plenty of useful pointers on improving my brushwork, level design, and gameplay difficulty.
      I've gotten back into the groove of chipping away at my reading and game list, as well as the endless FM catalogue here, but I may very well try my hand at the 15th anniversary contest should it materialize. That is assuming my eyes are ready for a few more months of Dark Radiant's bright interface while burning the midnight oil, of course!
      · 4 replies
×
×
  • Create New...