Doom 3 engine release and game code

[ceriux]

i read a bit back and someone said quake c is back ? so, will it be as easy to code for doom 3 as it is for quake?

[raynorpat]

Just finished most of my GLSL backend, so this should help somewhat. It's still missing environment bumpmapping and the ability to load custom GLSL shaders from a material.

I'm probably missing something in my shader implementation, since the flashlight acts strange on some materials.

Here's the ol' zip:

[mh]

[revelator]

Gonna ask ID on the bethesda blog how there stance is on using exsisting glsl shaders for reference.
With some luck i can maybe persuade them to release the glsl parts as part of the sdk (would be a huge help for beginners).

[raynorpat]

[mh]

[silverjoel]

Here's the source that can be compiled with VC++ Express. This was the iodoom3 guys idea, I just put it together.

https://sites.google.com/site/quakeupda ... ects=0&d=1

You need to compile it as debug without tools or release without tools.

[leileilol]

can sum1 port 2 the psp.

also port it 2 dreamcast as the dreamcast is most powerful video game console #1

[revelator]

i predict smoldering nah i guess most of the heavy stuff can be disabled the voodoo II port was a fine example of that.

[nbohr1more]

What do you think of this ATI paper about using Render to Vertex Buffer (R2VB) for dynamic shadow volume creation on the GPU (amongst other things) for DX10 style rendering on DX9 hardware:

http://www.csee.umbc.edu/~olano/s2006c0 ... ermann.pdf

???

[nbohr1more]

Not to spam this thread with tech demos (etc)... but what do you think of Humus's "Shadows that Rock" implementation for Shadow Mapping?

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

[mankrip]

[mh]

[nbohr1more]

Thanks for the feedback.

I've always thought Humus was one of the best at squeezing performance out of ATI hardware so it's a little surprising to hear his implementation wouldn't fare favorably.

(I guess it's easy to pull good FPS in these types of demos. )

I am still more curious about that R2VB method. I wanna see what Doom 3 runs like when every part of Stencil Volume is done on the GPU (including silhouettes).

I've been curious about this concept ever since I heard the first crabby rants about the CPU expense of the shadows over at Beyond3D after the game was released.

Is it worth being curious about it, or is that method also flawed in some way?

----

One other thing on the topic of maxing-out DX9 SM2.0 as a low-end target:

What do you think of using Alpha Test shaders to implement Dynamic Branching on SM 2.0 hardware?

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

[mh]

Doom 3 doesn't use branching in it's shaders, but there are a few other tricks you can do to simulate branching, like the MAX and MIN instructions.

Big problem with dynamic branching simulation using alpha test or stencil test is that it won't work with early-Z rejection as it depends on the fragment shaders executing. You'd get better performance out of Doom 3 by tweaking it to be early-Z friendly (in particular as it does a Z prepass and so is otherwise ideally set up for it - just that pesky stencil buffer use for everything kinda ruins it ).

None of that would have been an option when Doom 3 was originally developed as early Z in hardware didn't really exist at the time.

Second big problem about simulating branching with alpha test or stencil test is that it has to coexist peacefully with any other alpha test or stencil test that the engine does - and Doom 3 does a lot of both.

All academic however as the OpenGL asm shaders that Doom 3 used don't support branching anyway, and so Doom 3 doesn't need to use any kind of dynamic branching tricks.