Doom 3 engine release and game code

[mh]

I found the part of the code that was changed; look in draw_common.cpp and find this:

Code: Select all

	// patent-free work around
	if (!external)
	{
		// "preload" the stencil buffer with the number of volumes
		// that get clipped by the near or far clip plane
		qglStencilOp (GL_KEEP, tr.stencilDecr, tr.stencilDecr);
		GL_Cull (CT_FRONT_SIDED);
		RB_DrawShadowElementsWithCounters (tri, numIndexes);
		qglStencilOp (GL_KEEP, tr.stencilIncr, tr.stencilIncr);
		GL_Cull (CT_BACK_SIDED);
		RB_DrawShadowElementsWithCounters (tri, numIndexes);
	}

The reverse is really only relevant if the view is inside a shadow volume so in the common case it's not actually needed at all. No, the original code isn't there. Performance drops off maybe 25% or a little more for me with the new code.

Interesting that huge chunks of the console code are almost unchanged from Quake.

[mh]

glStencilOpSeparate.

Available on all hardware with OpenGL 2.0 or better, halves the number of passes needed to draw shadows, runs maybe 1.5 x faster on average (and even faster in scenes with heavy shadows, like the first map with the dropship).

Code: Select all

		if (!external)
		{
			qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, tr.stencilDecr, tr.stencilDecr);
			qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, tr.stencilIncr, tr.stencilIncr);

			RB_DrawShadowElementsWithCounters (tri, numIndexes);
		}

		qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_FRONT : GL_BACK, GL_KEEP, GL_KEEP, tr.stencilIncr);
		qglStencilOpSeparate (backEnd.viewDef->isMirror ? GL_BACK : GL_FRONT, GL_KEEP, GL_KEEP, tr.stencilDecr);

		RB_DrawShadowElementsWithCounters (tri, numIndexes);

You watching this, Spike.

[mh]

Interesting...

Here's the GL calls that the original code made; this was for the non-reverse case:

Code: Select all

glActiveStencilFaceEXT(GL_BACK)
glStencilOp(GL_KEEP,GL_KEEP,GL_INCR_WRAP)
glActiveStencilFaceEXT(GL_FRONT)
glStencilOp(GL_KEEP,GL_KEEP,GL_DECR_WRAP)
glEnable(GL_STENCIL_TEST_TWO_SIDE_EXT)
glDisable(GL_CULL_FACE)
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER,270)
glDrawElements(GL_TRIANGLES,480,GL_UNSIGNED_INT,0x0000) VP=5

And here's what Carmack's reverse looked like:

Code: Select all

glActiveStencilFaceEXT(GL_BACK)
glStencilOp(GL_KEEP,GL_DECR_WRAP,GL_KEEP)
glActiveStencilFaceEXT(GL_FRONT)
glStencilOp(GL_KEEP,GL_INCR_WRAP,GL_KEEP)
glEnable(GL_STENCIL_TEST_TWO_SIDE_EXT)
glDisable(GL_CULL_FACE)
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER,2208)
glDrawElements(GL_TRIANGLES,444,GL_UNSIGNED_INT,0x0000) VP=5  Time= 12us

It seems as though quite a lot more was changed for the released code than we were given to understand.....

Just tried out the reverse with glStencilOpSeparate and yes, it works.

[Spike]

your 'original code' uses calls to glActiveStencilFaceEXT, which is the nvidia-specific form of glStencilOpSeparateATI which was made core in gl3.

almost sounds like the patentless code supports only the common fallback case?

[mh]

The original code came from a GLIntercept log while the engine was running so I'm pretty certain that it's the Real Thing.

Guess you're right about the patentless code though.

[mh]

your 'original code' uses calls to glActiveStencilFaceEXT, which is the nvidia-specific form of glStencilOpSeparateATI which was made core in gl3.

almost sounds like the patentless code supports only the common fallback case?

According to http://www.opengl.org/sdk/docs/man/xhtml/glStencilOpSeparate.xml glStencilOpSeparate went core in 2.0, making it safer to use and less likely to need fallbacks.

[revelator]

agh missed the release.

Just returned from the hospital after having my gall bladder removed cause of a nasty infection.

Looking forward to play around with this though hmm some of the function names look suspiciously familiar ?.

[frag.machine]

agh missed the release.

Just returned from the hospital after having my gall bladder removed cause of a nasty infection.

Looking forward to play around with this though hmm some of the function names look suspiciously familiar ?.

Gall bladder ? Wow! Hope everything is ok now. My sister got some gall bladder issues years ago, luckily she got fine quickly (no surgery was required).

[qbism]

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.

How is this handled in the Linux build? No editor in Linux?

Get well soon, reckless.

[Eluan]

Nice to see so much Quake code into Doom3, especially that QuakeC is back! (well, more or less...)

[mh]

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.

How is this handled in the Linux build? No editor in Linux?

Get well soon, reckless.

edit_stub.cpp:

Code: Select all

void	RadiantInit( void ) { common->Printf( "The level editor Radiant only runs on Win32\n" ); }

And for every other tool.

[revelator]

thanks guys im ok just some aches in my stomach so i should be fine again in a few weeks.

hmm is'nt radiant based on gtk ? if it is it should work fine on linux.

[mh]

Not this Radiant; this one is heavily MFC.

[revelator]

Hmm ok well i bet the linux guys can whip something up, maybe modify gtkradiant ?.

Taking a quick stroll through the source since i cannot sit before my PC for very long at a time yet, it builds fine though it coughs a bit on some paths that the danish version of win7 does not have but else it seems to compile.

I understand that carmacks reverse was taken out though since its the Z-Fail method which rick also used in his early shadow volume code (long before carmack or creative) i dunno if were trespassing into creative land if we just slam together our own versions of the Z-Fail method ?.

[Spirit]

PVS-Studio: analyzing Doom 3 code: http://www.viva64.com/en/b/0120/


There is http://darkradiant.sourceforge.net/