Doom 3 engine release and game code

darkradiant ofc

hmm plenty possibilities QT which resembles MFC but can handle more complex operations and is availiable on both win32 and linux, gtk also works on windows but its a bit more painfull to use.
personally id prefer tools in QT but thats just me.

Hmm the game dll seems to have some problems building "unable to load default.cfg" i tried moving it into a subfolder named base with the built doom3.exe but still fails so something is acting up.

You need to set the basepath so where your baspeath is as default it uses the working directory.

  Code:

+set fs_basepath "C:\Program Files (x86)\Steam\steamapps\common\doom 3"


Hmm, well I've recreated the Reverse using two-sided stencil and it works perfectly, but I'm thinking that treading carefully is a better option. I'm certain that if there was an alternate way that could do it in one pass, and that didn't have patent heebeegeebies attached, JC would have included it in the released code. The two pass alternative (assuming you use two-sided stencil; 4-pass if not) only kicks in when the viewpoint is inside a shadow volume, so it's not really that big a deal to begin with.

darkradiant ofc

Hi, I'm one of the team members associated with The Dark Mod for Doom 3. Our upcoming Dark Radiant update is even closer to reaching feature parity with D3Edit. The new release will have animation previews, particle editing...and I'm sure a lot more. It's tailored for Darkmod editing but it also works with D3 and Quake 4. Should work with Prey as well. Now that the source code is released, hopefully we can achieve some tighter integration.

Hmm, well I've recreated the Reverse using two-sided stencil and it works perfectly, but I'm thinking that treading carefully is a better option.

Can this be done with a shadowmap and still side-step the patent lurkers, and still look better?

shadow mapping has no patents that I am aware of.

Does the engine have a built in light baking system or is it all stencil shadows.

Hi, I'm one of the team members associated with The Dark Mod for Doom 3. Our upcoming Dark Radiant update is even closer to reaching feature parity with D3Edit. The new release will have animation previews, particle editing...and I'm sure a lot more. It's tailored for Darkmod editing but it also works with D3 and Quake 4. Should work with Prey as well. Now that the source code is released, hopefully we can achieve some tighter integration.

Great

Hmm comes to mind several z-fail methods existed in the old tenebrae2 source (one for each card type if i remember correctly) we might end up making the code faster than it was to start with

ofc plenty new stuff that might work better.

Interestingly, the Reverse patent is probably unenforcable in the EU. Anybody fancy being a test case?

http://en.wikipedia.org/wiki/Software_p ... Convention

well im in the EU so if you like sure

A possible other alternative exists. This is fully depth-pass for both cases and seems to work in my (admittedly limited) testing so far.

  Code:

      if (external)
      {
         glDepthFunc (GL_LEQUAL);

         // view outside the shadow volume
         GL_TwoSidedStencil (backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, GL_KEEP, tr.stencilIncr);
         GL_TwoSidedStencil (backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, GL_KEEP, tr.stencilDecr);

         RB_DrawShadowElementsWithCounters (tri, numIndexes);
      }
      else
      {
         glDepthFunc (GL_GEQUAL);

         // view inside the shadow volume
         GL_TwoSidedStencil (backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, GL_KEEP, tr.stencilDecr);
         GL_TwoSidedStencil (backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, GL_KEEP, tr.stencilIncr);

         RB_DrawShadowElementsWithCounters (tri, numIndexes);
      }

"GL_TwoSidedStencil" just selects the appropriate two-sided stencil algorithm to use (EXT, ATI or core GL 2.0); on GL 2.0 or better hardware you'd just replace it with a call to glStencilOpSeparate.

If this does turn out to be a robust replacement that doesn't violate the patent, it just shows even more clearly how utterly nuts the patent was to begin with.

gonna try it out ill report back.

Just re-read the Creative patent; it seems as though this kind of depth-test inversion was what the patent specifically referred to, so it's not safe to use. It does mean that their claim with reference to the Doom 3 method (zfail) seems to be on somewhat shakier grounds though.

Working on a GLSL backend:



btw, has anyone checked out draw_exp.cpp?