Doom 3 engine release and game code

[revelator]

[mh]

VBOs should be automatically destroyed when the GL context is destroyed, so there's no need to free them. They're just GPU resources same as textures.

That's assuming that your driver is doing it's job right, of course.

On the other hand, if it improves the signal-to-noise ratio of any debugging tools you're using, then by all means do it.

[revelator]

Ok then

Im allmost certain i got the showel to the performance bug also but the bugger was not where i expected

I had a look at some debug warnings and noticed the console spamming messages like empty filename whenever performance took a nosedive so i did some searching and i think i now understand why
using _malloca gave me atleast some fps increase. The function spamming that message uses _alloca to allocate messages but what happens when it tries to pass a NULL pointer (empty filename) to the stack
So i disabled the spammer and just skipped processing it in that case. Well the result was blowing my mind my FPS skyrocketed somewhat (200% increase) the funny thing is i newer touched that codepart before i noticed the spam so my other fixes actually worked, now color me pink and call me an elephant

[nbohr1more]

[revelator]

[revelator]

Btw i updated the OpenAL / ogg and vorbis sources to latest versions in my engine

[nbohr1more]

Thanks again.

I forgot to mention that read-only SVN access to the latest development builds is also available.

http://www.thedarkmod.com/downloads/

Though it would probably be best to pilot this stuff in the current release.

The mkdir changes you've done look familiar... I think one of the folks working on an OSX build mentioned something
similar...

[revelator]

The mkdir function i posted been in my realm engine for ages
I think it originated from bengt jardrups quake port.

[nbohr1more]

Good deal.

Looks like one of the devs has been hankering to get rid of Boost dependencies because of all the problems that have cropped-up
in modern Linux distros. One down, ???# to go...

[revelator]

Probably preferable to use STLPort functions instead ?
Also one of the things im cleaning up as i go is the abundance of C type calls like (void *) and instead using real C++ like reinterpret_cast<void *>(somepointer);
some types have to be const_cast or static_cast but msvc is pretty good at pointing that out

As for STLPort i posted in another thread here the latest version patched for msvc2010 and 2012 since the dev who maintains it have not gotten around to that yet.
It does work cause i built my Doom3 against it hehe.

[revelator]

Something else i been trying to wrap my head around.

Since i changed the old glVertexPointer glTexCoordPointer calls to use glVertexAttribPointer i had to do quite some guesswork as to the index locations.
For one glVertexAttribPointer(2, 3, GL_FLOAT, false, sizeof(idDrawVert), ac->normal.ToFloatPtr()); in draw_common.cpp uses index 2 while it uses index 11 in draw_arb2.cpp
changing it to 11 works but i noticed something strange with reflections being REALLY reflective if i do that
So normals can have another index and reacts differently hum ??? now i know with glsl that i can get the correct index number via a glGet call but im not sure how to go about this with ARB assembly.

Ill only use this to get the known index numbers which i will then hardcode into an enumerator (should be somewhat faster) but i need a function that can do this.

these are the ones i been able to find so far.

glEnableVertexAttribArray(0); // vertex
glDisableVertexAttribArray(2); // also uses the normals for reflection
glDisableVertexAttribArray(3); // color
glEnableVertexAttribArray (8); // texcoord
glDisableVertexAttribArray(9); // tangents 0
glDisableVertexAttribArray(10); // tangents 1
glDisableVertexAttribArray(11); // normals

this is from the setup that works.

[mh]

[revelator]

so array index 11 is using normals as texture coordinates and the higher numbered indexes are multitexture.
I seen an example where the glsl backend used offsetof to get the index number directly from the shader

[revelator]

example of new layout.

i changed all the old C style casts to C++

vrefs = reinterpret_cast<vertRef_t **>(_alloca32(numVerts * sizeof(*vrefs)));

_alloca32 is my own implementation that uses SEH exceptions to try and avoid stack failures. Atm its a function but im working on turning it into a macro.

typecasting in C++ can be dangerous as opposed to C style casting it actually converts the return values to the type casted to, it seems to work allright though

[revelator]