motorsep

Currently, BFG engine is as fast as it can get. If rendering of transparent surfaces, physics and collisions are threaded. Then you can squeeze out even more performance boost. However, knowing what's involved into job queues threading, I don't think it's practical to do so. Forward+ rendering and fast shadow mapping (not what tr3b has in RBDoom 3 BFG, which is _slow_) would bring really nice performance boost, but afaik forward+ requires OpenGL 4.x. In other words, at this time, so sake of compatibility with older hardware, I think BFG engine is really solid engine to use, without any fancy rendering enhancements.

Not a problem. What I am trying to get at is that finding gameplay programmer who can port game code from one codebase to another, especially when there is virtually no difference between stock codebases, is infinitely easier than finding a deep engine programmer, who can take old engine arch circa 2004, and turn it into modern code base, with performance matching leading engines (or even just getting noticeably better). I still can not find available Cg/HLSL shader programmer, paid. Not to mention OpenGL / physics / particles programmers (paid also). Literally, there are not enough qualified workforce out there, especially when AAA companies are willing to pay big dollars for good programmers.

I don't see how I am going to benefit, if we already got the engine to the release state with almost all features we need for the game. I am almost certain what's really needed won't be fixed, since it hasn't been fixed to the date by anyone in any idTech 4 / BFG fork. Sorry for being blunt. I don't really care if TDM goes with BFG. I am just pointing out the reality of things when it comes to improving idTech 4 vs going with BFG (or even Storm Engine 2 when it's out to the public). Just think about it - all this time various devs have been trying to make idtech 4 perform better, and failed. At the same time it took us less time to fix BFG, make it moddable and improve rendering.

BFG uses exactly same maps and all same assets as Doom 3. It automatically binarizes/compresses them into binary formats. So you won't even have to mess with maps to make them work with BFG engine. I don't see how it is an issue. I don't know who LightGem works exactly, but I assume it works based on information in .proc file, which contains precompiled shadow volumes. For testing purposes, compile a map without shadow volumes and see how AI reacts to it. It it works as expected, then it's something else. Either way, shadows in Doom 3 BFG are as dark as in Doom 3. The only thing that makes BFG brighter is perhaps light scale cvar and primitive bloom. Afaik, Doom 3 runs rendering on one core, and the rest on second core, if available (particularly sound engine). You already having 2 cores occupied. So people with dual-core CPUs won't feel any performance boost with OpenMP.

How can you break maps with new engine? OpenMP is not a solution as it uses physical cores. So you have 2 cores, rendering runs on one, sounds runs on another. That's it, no more cores, no more performance increase.

I understand moving stuff to another engine. But dhewm3/RBDoom3/etc. (any idTech 4 fork) is the same engine that runs TDM. Game code is 99.9% the same as Doom 3, all assets are exactly the same, etc. One thing is guaranteed - you can't bring BFG engine coolness into TDM as easy (or perhaps it's not even going to happen) as you could port TDM code into BFG codebase.

Thanks I am going to release Storm Engine 1 soon (dhewm3 + tools + few rendering enhancements), but I wonder if anyone even care.

Finally, put together a video showing progress on the game I have been working on. The video particularly shows progress made on the engine:

Looking at the rate of adoption of BFG engine, I'd say it's nearly impossible

Note that in BFG engine, entire game code is not threaded (physics, AI, etc.). It just runs on a separate thread from anything else, thus performance much better than idTech 4 game code. RAGE on the other hand has AI and physics on separate threads (there maybe more or less separation going on, I am not 100% sure). It was hell of a work to thread it to my understanding, so I wouldn't count on having it done in the garage, especially using idTech 4.

How would I go about disabling stamina for the first 5 seconds after player begins running, and then make it kick in after 5 sec. is up ? In other words, player starts running, runs for 5 seconds without draining stamina, then stamina starts draining. Another thing is that player slows down as stamina depletes. How do I make him not slow down and run at the same speed until stamina is out? I found stamina code, but it's kinda tangled up :/ Thanks.

oh, what's wrong with using new TDM ?

Supposedly that isn't complete water physics mod. Rumor has it TDM has better water physics code.

Oh, I don't mean to disable water physics. I mean to diff the code for water physics to make it available for general modding of idtech 4 engines. Would I be able to find all the water code by #ifdef MOD_WATERPHYSICS ? Are there any parts to it that aren't #ifdef'ed ?

Can someone on TDM team, familiar with the water physics code weed out water physics code from TDM codebase ?

What doesn't look silly to you? (besides TDM)

Doom: http://www.doom.com

So, while video isn't done yet, here is a small update on progress with Phaeton (ex-Steel Storm 2, powered by modified Doom 3 BFG engine): http://www.kot-in-ac...m/blog_new.html

When you run our of physical RAM, then you can think of 64bit. Otherwise all those limits are artificial. When TDM starts using more RAM than your 32bit system with 4Gb of RAM, then you can say TDM needs to go 64bit. Doom 3 BFG engine uses YCoCg compression, so even with 2048x2048 textures it uses probably as much VRAM as original Doom 3 does, with almost identical quality (vanilla BFG has crappy encoder, which we fixed to provide the best quality possible using YCoCg scaled DXT5 compression; which is noticeably better than DXT5 used in Doom 3, and in many modern games).

There is no benefit running 64bit build at all, unless collisions are fixed. Also, if there are no huge massive levels with tons of models and animations and 2048^2 and larger textures, there is no need in 64bit builds either. If one decides going 64bit, it has to be 64bit exclusively and have that much of content per level that 32bit build can not handle.

No, I don't have any plans for now putting in shadow maps from RBDoom 3 BFG fork. The implementation requires to have 256bit VRAM (even then it's still slower than shadow volumes) and that's not cheap hardware. The only reason to go with shadow maps is deferred / forward+ (tiled) renderer, which will require a massive rewrite of the renderer. It's beneficial in a long run, but as it stands now, shadow volumes are fastest solution, provides quite decent look and allows for wide range of hardware to be played on. I am hoping to make a video overview of what's been done to the engine so far, this weekend. I'll post link here when it's up.

Fork of Doom 3 BFG engine (or rather fork of RBDoom 3 BFG fork; fork of a fork )

I have a gut feeling LH will tell you no, and will recommend going with BFG engine instead. ARB shaders are atrocity that will not be supported eventually anyway by neither AMD nor Nvidia. If TDM team has a strong desire to move to BFG engine, just wait until we release our fork to the public - fixed major bugs, ported all tools (and fixed them), improved renderer.

YOu don't need to re-pack .resources to play texture mods. For once, BFG has no support for offset mapping, so none of the displacement maps will work with BFG out of the box. If original materials were edited to accommodate those mods' features, then you won't see any materials in-game. All you need to do to mod BFG is to extract everything from resources, except sounds, and that's all you gotta do. Make a map for Doom 3, put it into some mod folder, run BFG with several cmd line parameters, load map file and off you go.

You need 64bit HDR renderer with dither post process, to have no banding. Otherwise there is no way around that for DXT5 DDS images. 24bit TGA should have no banding.