Doom 3 engine release and game code

[revelator]

Might be Cg also the bfg edition is lots faster so im looking forward to see the changes

[revelator]

Thought i had nailed the ATI bug with my new version but im still getting reports from users saying that they only get about 2 fps with it sigh .

Im unable to find out what may cause this but if its the removal of ATI specific render code then i give up :S

[revelator]

[mh]

How about making a guess based on the GL_VERSION? Something like: if it's 2.0 or 2.1 assume 256, if it's 3.x assume 512, 4.x or higher assume 1 GB? Or even just assume at least 1 GB and unlock Ultra mode/etc.

Doom 3's extension getting interface is bugged by the way. It gets extensions based on "GL_ARB_extension_name_goes_here", whereas it should be "GL_ARB_extension_name_goes_here " - the GL spec specifies that the extensions string is space-delimited, and the original code will fail on a driver that exports "GL_ARB_extension_name_goes_here_and_more_text" but not "GL_ARB_extension_name_goes_here".

Or even better, just use GLEW and drop the old "qgl" crap.

[Spike]

glGetString(GL_EXTENSIONS) is removed in gl3 core for reasons like that.

[revelator]

Yep working on that still few hurdles im using the source mh provided me with earlier but it has a weird bug that causes models to be lighted oddly.

I also nailed the FPS drop my source has in comparison with normal Doom3 its caused by the shared ARB2/GLSL renderer the original ARB2 only backend does rendering twice as fast as to what causes it im not sure tbh but maybe mh had an idea. Found out the hard way by reverting draw_arb2.cpp.

[revelator]

Rofl well i finally nailed the weird shading but it was not in a place i would have expected Seems mh's early source was subject to some experimentation so he removed a ton of the image code
like downsampling blendmodes etc. Well the blendmode he had set fubared the model shading so i reverted most of it and now it works 100%.



Try it out and let me know how it works for you im also interrested in hearing if ATI users have any problems with this.

[mh]

The shared ARB2/GLSL renderer needs to switch back and forth between both shader types in order to draw shadows/surfaces/shadows/surfaces/etc, so there's a lot of "switch off ARB2/switch on GLSL/draw/switch off GLSL/switch on ARB2/draw" and so forth. A GLSL replacement for the shadow program wouldn't be a bad idea to prevent that.

In theory there should be absolutely minimal difference in performance between ARB shaders and GLSL. A really good GLSL compiler could pull some optimizations, including platform-specific optimizations, that hand-written ARB shaders might miss, so if anything GLSL may run faster - provided that switching didn't happen.

GLSL also allows for functionality from higher GL_VERSIONs that can run faster, whereas ARB shaders (with the exception of NVIDIA's proprietary extensions) don't.

So the summary is that there's no future in maintaining the ARB backend, but it does need a full switchover for all of the other shaders first.

Right now I've no major interest in the Doom 3 code; waiting on the BFG edition GPL release, then things should get exciting!

[revelator]

Aye also looking forward to see what the BFG edition code looks like

State changes ... shudder well it certainly makes a rather hefty impact on fps :S might explain whats going on.
Btw just for the lulz i tried using your optmized memcpy for copying the matrixes. It netted me an fps increase of 10 fps nice job m8.

Your old code might be nice for someone as a cleansrc though it runs pretty well here but im still scared like hell of those ATI users

[mh]

[revelator]

Quite a lot slower :/ the SIMD memcpy also uses asm but speedwise they are not nice.
Asm can be a bitch to learn so Hats of for your first attempt to work this nicely

[revelator]

Source here

[Barnes]

[revelator]

Hmm interresting using the VBO's as a way to get videomem thanks.

[revelator]