Doom 3 engine release and game code

[mh]

ES2 is not the same as regular GL. There is some feature overlap, but there are some things in ES2 that are not in desktop GL, and a veritable boatload in desktop GL that are not in ES2.

Been doing some playing around with the vertexcache.cpp code recently; there is a major performance bottleneck in here because it uses the original GL_ARB_vertex_buffer_object extension, which is absolutely useless on it's own when it comes to dynamic data. The main problem is that it causes constant CPU/GPU synchronization, which breaks parallelism and means that each processor needs to constantly go idle while waiting for the other to catch up. Added some basic GL_ARB_map_buffer_range support which is a huge performance boost (this change alone got my experimental Q2 engine going twice as fast), but I fear that a full exploitation of the potential would need a complete gutting of this code.

[motorsep]

Do you have it as a patch for vanilla Doom 3 to boost performance? What does it break?

[mh]

The current codebase I have is unusable with vanilla - I'm using GLEW for extensions so the "qgl" stuff is all gone, I've removed fallback paths, etc. I could throw my vertexcache.cpp up on pastebin, but someone else would need to do the grunt work of adapting it to vanilla; I no longer have any interest in mucking around with the pain and suffering caused by retaining downlevel support. It's also heavily untested, by the way - most I've done is a 10 min jog through the first part of Delta 2.

[motorsep]

Could you make a patch to speed up vanilla Doom 3 with ARB path?

[revelator]

i Guess it depends on opengl ES support if even possible.
I know glsl is newer than the ARB path does not mean though that all development stopped on it the day they got glsl its still being updated and newer features still going in.

[revelator]

[mh]

[revelator]

Was more out of curiosity but thanks for explaning.

[mh]

[revelator]

[mh]

So it was just the calls to common->Printf that caused it?

[revelator]

Hmm no it was this part

// determine which back end we will use
// ??? this is invalid here as there is not enough information to set it up correctly
SetBackEndRenderer();

ID even marked it as faulty but left it in anyway xD its called in the right place somewhere else also though,
but removing the old deprecated arb 1.0 backend causes it to get confused because the nessesary data for telling the engine if the backend was enabled was not yet parsed,
so we end up with an undefined situation.

Major bummer newer leave things you know dont work even if you fixed the problem elsewhere hehe.

[revelator]

[mh]

Ah, OK. I'd already killed that myself anyway (as well as some of the variables it sets - like overbright level), but it's still useful to know.

[revelator]

Indeed Also a few other things that need a lookover according to PVS-Studio (fixed most allready but theres still a few im not certain of like the multitude of calls that are newer tried against nullptr.
Ive ditched parralax shading since it looks dreadfull with highres textures on non flat surfaces instead im going to look into tesselation.
Parralax shaders could be used though for raising certain textures but it would need to be changed to a content shader with a big fat warning sign to mappers that its not intended for non flat surfaces.