Doom 3 engine release and game code

[ceriux]

WoW can U port it to the psp.

http://www.moddb.com/mods/doom3psp

[Spirit]

WoW can U port it to the psp.

http://www.moddb.com/mods/doom3psp

http://www.moddb.com/mods/doom3psp/downloads

[ceriux]

lol its just a joke i think i told the guy who was doing it he'll never complete it. i didnt think it would work out too well.

[r00k]

here i thought psp meant PrettyStupidPlayers, now i find it really means PrettyStupidProjects

[revelator]

Try looking up dante doom3

[revelator]

Killed the last vestages of the deprecated vertex client calls everything now uses VertexAttribArray. Last one was a bugger that took me some digging to fix, turned out mh had the attrib for normals set at 2
but its 11 everywhere else that fixed the weird textures i got on the last try.

heres the correct one.

Code: Select all

glVertexAttribPointerARB(11, 3, GL_FLOAT, false, sizeof(idDrawVert), ac->normal.ToFloatPtr());

[revelator]

Hunting the ATI bug i went to some extrenes to figure out why my port was slower on some operations than the standard doom3 build and i kinda hit something.
Well the good news is that my code is loads closer to modern hardware the bad is that Doom3 still uses a heap of deprecated crap like glColor glGet etc.
So i ran the bugger through glintercept and gdebugger and the result was rather scary those old calls makes a crapload of state changes (several thousand per second) and are really hampering
performance now that i removed the old support mechanisms. VBO is actually ultra fast for the calls it handles the graph was barely noticable, whereas the old gunk made the performance graph shoot through the roof

Not only do they make a ton of unnessesary state changes they also leak memory like theres no tomorrow
BFG edition source cant come soon enough

[mh]

Ha ha, yeah.

The original code is a special kind of nasty.

Can't really be blamed as nobody actually knew how to do VBOs properly in GL at the time, but it's still quite nasty.

[nbohr1more]

Hmm. This may be why TDM 1.08 is getting malloc errors for many users during map loads while the previous
version didn't. Maybe ATI's driver did a better job of managing those legacy calls and the memory states they created
and we are no longer benefiting from this on GPL builds.

[bugmenot]

I just wanted to say thanks and great work to everyone here who's been working on this code; the source was released about a year ago, but this is the only place I've found that seems to be doing any active development and improvement. Both iodoom and dhewm3 appear to be stalled or dead, as they haven't had any git commits in many months.

With the release of the BFG Edition, I became interested in playing Doom 3 again, so I dug up my old retail copy and got it running under Linux Mint. I'm using id's last official Linux release (from 2007), and I'm curious as to whether or not I'd get better performance out of one of the more recent builds. I'm running an older, lower-end system with an integrated GeForce 6150 SE, but it runs the game surprisingly well; turn off the shadows and everything else runs more or less smoothly, even at High Quality (the first system I ever played Doom 3 on was one purchased in 2004, when the game first came out; it had a GeForce MMX 440 and had to be run at the lowest settings). I'm not a coder and don't have a lot of experience with compiling my own programs, but I'm willing to jump through some hoops if it'll make for a prettier game, or one that runs with a little less stutter.

Does anyone have any suggestions for what would be best, like the GPL release, or one of the builds posted here? I'm not tremendously interested in running any exotic mods, as the system probably wouldn't be able to handle them anyway, so just vanilla Doom 3 and RoE will work fine.

Thanks again, and keep up the good work!

[revelator]

Could very well be nbor one particular interresting thing i noticed was that idtech 4 defaulted indexbuffers to off even on cards that supported vertex buffer objects
on mine there on by default so i wondered if that was causing the slowdowns somehow but even off its still slower than the unmodified build
So i had to use an OpenGL debugger to see where things go wrong.
Its extremely nasty indeed

Weirdest thing is replacing the old nasty _alloca by the safer _malloca speeds up stuff majorly but the modifications needed are rather scary in themself as you need to use _freea() on all of the calls (100's of them) though _freea() will only free if something overshoots _allocas stack limit and starts using heap memory instead.

As for OpenGL the number one cullprit for bad performance was (hold on) glColor4f

And to the Guy or Girl (hard to know) in the last post before mine.
Depends dhewm3 works rather well but is not compatible with current mods unless you recompile there game dll's with dhewm3 as the sdk (protocol change).
When the BFG edition source gets released we will probably merge fixes id has made to the source into the old code and avoid using parts that break compatibility with it.
The render backend will also get a good look at as it seems id have fixed the non used exp backend allowing for shadow maps / bloom etc.

So if not using mods dhewm3 is a good choice else theres a few sources on github with some fixes but you need to compile them yourself or ask someone to.

[revelator]

glColor4fv, 14768, 7385, 7383, 49.99%
glTexGenf, 5600, 0, 5600, 100.00%
glPolygonOffset, 2367, 9, 2358, 99.62%
glColorMask, 1704, 0, 1704, 100.00%
glStencilFunc, 1709, 223, 1486, 86.95%
glTexEnvi, 1400, 0, 1400, 100.00%
glScissor, 1305, 180, 1125, 86.21%
glPolygonMode, 700, 0, 700, 100.00%
glViewport, 748, 92, 656, 87.70%
glColor3f, 751, 151, 600, 79.89%
glCullFace, 1158, 700, 458, 39.55%
glDepthMask, 1494, 1143, 351, 23.49%
glClearDepth, 350, 0, 350, 100.00%
glColor4f, 350, 0, 350, 100.00%
glDepthFunc, 1977, 1627, 350, 17.70%
glDrawBuffer, 350, 0, 350, 100.00%
glShadeModel, 350, 0, 350, 100.00%
glClearColor, 350, 1, 349, 99.71%
glActiveTexture, 26521, 26277, 244, 0.92%
glReadBuffer, 206, 0, 206, 100.00%
glAlphaFunc, 130, 1, 129, 99.23%
glClearStencil, 111, 1, 110, 99.10%
glStencilMask, 111, 1, 110, 99.10%
glDepthRange, 98, 0, 98, 100.00%
glBlendFunc, 2551, 2550, 1, 0.04%
glDisable - GL_TEXTURE_2D, 2011, 2011, 0, 0.00%
glDisable - GL_TEXTURE_CUBE_MAP, 1545, 1545, 0, 0.00%
glDisable - GL_LIGHTING, 351, 351, 0, 0.00%
glDisable - GL_LINE_STIPPLE, 351, 351, 0, 0.00%
glDisable - GL_STENCIL_TEST, 1735, 1735, 0, 0.00%
glDisable - GL_TEXTURE_3D, 1401, 1401, 0, 0.00%
glDisable - GL_ALPHA_TEST, 481, 481, 0, 0.00%
glDisable - GL_DEPTH_TEST, 638, 638, 0, 0.00%
glDisable - GL_VERTEX_PROGRAM_ARB, 2319, 2319, 0, 0.00%
glDisable - GL_FRAGMENT_PROGRAM_ARB, 1572, 1572, 0, 0.00%
glDisable - GL_POLYGON_OFFSET_FILL, 2257, 2257, 0, 0.00%
glDisable - GL_CULL_FACE, 61, 61, 0, 0.00%
glEnable - GL_TEXTURE_2D, 964, 964, 0, 0.00%
glEnable - GL_TEXTURE_CUBE_MAP, 146, 146, 0, 0.00%
glEnable - GL_DEPTH_TEST, 462, 462, 0, 0.00%
glEnable - GL_BLEND, 351, 351, 0, 0.00%
glEnable - GL_SCISSOR_TEST, 351, 351, 0, 0.00%
glEnable - GL_CULL_FACE, 411, 411, 0, 0.00%
glEnable - GL_STENCIL_TEST, 859, 859, 0, 0.00%
glEnable - GL_ALPHA_TEST, 131, 131, 0, 0.00%
glEnable - GL_VERTEX_PROGRAM_ARB, 1662, 1662, 0, 0.00%
glEnable - GL_FRAGMENT_PROGRAM_ARB, 1573, 1573, 0, 0.00%
glEnable - GL_POLYGON_OFFSET_FILL, 2257, 2257, 0, 0.00%
glMatrixMode, 5784, 5784, 0, 0.00%
glBindBuffer - GL_ARRAY_BUFFER, 11780, 11780, 0, 0.00%
glBindBuffer - GL_ELEMENT_ARRAY_BUFFER, 9300, 9300, 0, 0.00%
Total (51 items), 117912, 91094, 26818, 22.74%

just a taste of the numbers of redundant state changes in Doom3

So theres definatly room for a major overhaul

[mh]

Could very well be nbor one particular interresting thing i noticed was that idtech 4 defaulted indexbuffers to off even on cards that supported vertex buffer objects

Much hardware of the time didn't really support index buffers in GPU memory, and even hardware that did support them was more likely to only support 16-bit indexes (Doom 3 used 32-bit) so that's a fairly unsurprising choice. The alternative would have dropped the entire vertex piepeline back to software emulation in the worst case. All those problems are gone away nowadays of course.

[revelator]

Dunno my early geforce 6600 seems to handle indexbuffers quite ok but i think Doom3 came out in the days of the ti4200 which might not have had the muscle.
Strangely enough my old radeon 100 plays Doom3 fairly well (not on ultra or high but that figures) so the performance thing is something im a bit baffled about.

[mh]

A 6600 shoudl be good, but Doom 3 pitched it's hardware requirements as far back as the GeForce 3; the 6 series was still quite new and high-end when it launched.