Doom 3 engine release and game code

[revelator]

[Barnes]

[revelator]

thanks barnes but there not the same in doom3 thats why i been very carefull not to name them yet.

for one the color attrib in doom3 is 3 not 2 as for the texcoord ones the only one doom3 ever uses is attrib 8 which it also uses for some hokery pokery on normals for the skybox effects.

its very confusingingly setup

just to try it out so as to not speak out of my ass i tried with yours and the result was pretty funny to look at atleast untill the whole thing crashed hehe.

[mh]

The thing about vertex attrib arrays is that you don't have to map them to the old-style arrays. Just pick a number (up to, normally, 15) and set up the array; so long as you use the matching attrib number to read from in your shader, it works.

GL_ARB_vertex_program defines the mapping for backwards-compatibility purposes; GLSL doesn't. So in theory you can mix and match old-style arrays and attrib arrays in your code if using GL_ARB_vertex_program, but in practice it's supposed to be disallowed by the spec (the fact that vanilla Doom 3 uses it despite that is quite evil). If using GLSL you should normally just use attrib arrays with either glBindAttribLocation or "layout(location=" syntax, depending on the GLSL version you're targetting.

[Spike]

glsl allows for attribute 0 to alias vertex coords (my ati 9600 pro drivers do this - disabling the attribute also disables GL_VERTEX_ARRAY, not seen that on more recent hardware though).
Other attributes are not meant to alias anything, but if you don't adhere to hardware expectations then you'll have a performance reduction due to the driver having to recompile or remap things weirdly or something, even if you're adhering to the spec.

[revelator]

Hmm interresting that might explain why my engine is slower than the stock doom3
i also spotted a bug in my driver it seems as the shadow.vp is throwing an error about the position not being -1 weirdly enough it works most of the time but i noticed sometimes shadows get turned off.

[mh]

My own gut feeling is that should really only be relevant to older hardware. By the time you get to SM3-class stuff, which specifies generic attributes from the outset, it should be a total non-issue.

[revelator]

heh my gfx card is an nvidia 560 gtx but i guess you didnt mean my exact hardware
i hope i can solve this, the jump to C++ was bad enough but shaders eurgh

Btw GLEw is now compiled as part of the engine so no need to setup paths for libraries though the wgl extensions are still a problem its no worse than having to initialize them and you can safely remove all the
typedeffed crap in win_glimp.cpp.

Another huge performance monster we have identified at doom3world is the script lexer and bloodrayne is working on moving the more abrasive functions engine side
which should net us a rather huge performance increase.

[revelator]

Looks like this now



im preparing an update package for Doom3 that can be used with pretty much any doom3 engine but will probably look best with mine
since im defaulting engine settings to max on ultra and pretty high on high setting

you get a new menu for Doom3 with widescreen support, updated textures/models, shaders with support for ambient light (makes it bright enough that you wont miss having the flashlight out with your weapon).
Shaders now default to OPTION ARB_precision_hint_nicest for higher precision. Theres no bloom shader or anything special only reworked versions of the original shaders. If you want bllom theres several mods out there for that .

Textures are oversized so i decided to not yank them in a pk4 since the size would break Doom3 from loading it on 32 bit OS (yes there is a limit its around 2 gb i found out by testing).
I also made high res dds versions so people who can not run doom3 on ultra or high can still have nice textures.

[Barnes]

all shaders from doom3bfg (arb, glsl, hlsl)

[revelator]

Heh nice i see id has seriously upped the functions to use shaders with the bfg edition.
Cant wait to have a look at it

[Barnes]

Carmak use half angle for specular in glsl..... in 2004 he said he was going to get away from that

[revelator]

guess he wanted something left in there for us to fiddle with
looks like the new bugger has shadowmapping also wohoo
and he moved both the gui and fog to shaders.
weirdly enough it still incudes the cg shaders i wonder if the code for them is working in the bfg edition since in the GPL release the code was missing.
and the depth buffer is finally accessible via shaders to it seems that bodes well for ssao fans

heh and ambient light is still disabled but reb fixed that years ago

# ambient lighting
# MOV light, localNormal.z;

[mh]

A simple quality improvement is to renormalize the half-angle in the fragment shader. That tightens things up quite a good deal and gets rid of a lot of the smudgy/blurry look of the original. Not sure if BFG does that (from the looks of things it doesn't) but if you're not, you should.

[revelator]

the shaders i can recognize the names of are 100% comparable to the old doom3 shaders so my guess is no though they did move more of the renderer to the shaders

I think sikkpin does something like that as his interaction shader is a lot clearer than the original.