Doom 3 BFG Edition and TDM sitting in a tree

[Serpentine]

Most of the map load is already just reading in binaries, the .map is a really minor part in the grand scheme. Rather the gain comes from the replaced resource management/loader/storage format - which changes just about everything. That said, there's not a chance I'd be happy implementing it in the current non-zip way.

 

Load times are really really low if normalmaps are pre-compressed. <5 seconds to load the training mission from cold on my cheapo ssd. Once we get there, no problems.

 

But yeah, the code is vastly different to the existing stuff - only a very few sections are really easily portable. I don't see this being a big source of stuff outside of the render stuff (which I havent looked into much). ATM my work is going into making the TDM build system(s) sane(because 3 completely different systems is retarded) and code more portable, I'd like that done before anyone starts playing with this.

 

The font support seems interesting, seems to make packed rasters automatically... that might be very nifty.

[Springheel]

Load times are really really low if normalmaps are pre-compressed. <5 seconds to load the training mission from cold on my cheapo ssd. Once we get there, no problems.

 

We'd like to address that for the next update.

[Tels]

Most of the map load is already just reading in binaries, the .map is a really minor part in the grand scheme. Rather the gain comes from the replaced resource management/loader/storage format - which changes just about everything. That said, there's not a chance I'd be happy implementing it in the current non-zip way.

 

Load times are really really low if normalmaps are pre-compressed. <5 seconds to load the training mission from cold on my cheapo ssd. Once we get there, no problems.

 

But yeah, the code is vastly different to the existing stuff - only a very few sections are really easily portable. I don't see this being a big source of stuff outside of the render stuff (which I havent looked into much). ATM my work is going into making the TDM build system(s) sane(because 3 completely different systems is retarded) and code more portable, I'd like that done before anyone starts playing with this.

 

Yeah, that would be really really cool!

 

The font support seems interesting, seems to make packed rasters automatically... that might be very nifty.

 

I had hoped for TTF and Unicode (and maybe even "render HTML") support, because that would simplify a LOT of things for the GUI.

[Baddcog]

Hate to burst anyone's anti-Steam bubble...

 

but regular edition is back up at $5.99, compared to 24.99 for BFG edition. Improvements are always welcome but i don't want to buy Doom3 again, especially at $25.

[Tels]

Hate to burst anyone's anti-Steam bubble...

 

but regular edition is back up at $5.99, compared to 24.99 for BFG edition. Improvements are always welcome but i don't want to buy Doom3 again, especially at $25.

 

If we backport and BFG code to the TDM engine, then it will work with regular D3 (we aren't using the actual engine or game code, just some assets, anyway).

 

Plus, the aim is for the next version to be stand-alone, so D3 or BFG do no longer matter at all. We just get some new code merged into our code base.

[New Horizon]

Hate to burst anyone's anti-Steam bubble...

 

but regular edition is back up at $5.99, compared to 24.99 for BFG edition. Improvements are always welcome but i don't want to buy Doom3 again, especially at $25.

 

Porting code from BFG has zero impact on what version of Doom is required.

[Serpentine]

You cant use the BFG resource files at all, unless we moved completely to its engine... which isn't going to happen.

 

I poked dhewg about if he'd be backporting changes, he said he's interested but no commitment to it at this stage. Since I'm working to bring TDM closer to his work at the moment (it's very subtly different, but brings in a lot of advantages), we might be able to pick out the cherries in an easier manner. The only real pick up is the render changes, which if they're possible to move over easily; would be a massive boon with texture compression and glsl support (with all of the shaders now released too - no need to re-write any). Time will tell.

 

Really, the code is nice to have and might give us stuff... but at this stage it'd be foolish to try grab things so soon.

[lost_soul]

Does this mean I can get a used copy of BFG Edition, compile the engine myself, and not have to use Steam or support Bethesda? I've compiled plenty of stuff on Linux, but never on Windows. It would be an educational experience.

[nbohr1more]

Tr3B has divulged a little more about his engine changes.

 

What about your idtech4cdk renderer? Wasn't the shadow mapping implementation already better?

 

Working with WGL pixelbuffers for shadow mapping is really a method from 2004 .. I think at least your initial approach with FBOs was better.

I tried to fix the exp renderer in march and my first impression was that it was damn slow.

There were too many context switches for shadow mapping and interaction rendering. I got like 20 fps.

After that I supplemented the exp backend with my XreaL GLSL interface and my approach to render shadowmaps and especially point light shadow cubes. I use FBOs and that way I get stable 70 - 90 fps on a Geforce GTX 275. I can recommend shadow mapping with Doom 3 because it scales very well with newer gfx cards. I get 120 fps on my new GTX 660 Ti and the Doom 3 scenes are usually a nightmare for shadow mapping. I think almost no game has so many point lights that cast shadows. We also made a few tests with other commercial engines and they weren't faster.

 

One way you can really improve speed is by implementing light pre pass deferred shading. Standard deferred shading is too fillrate limited because the gbuffer is too fat. It is a trade-off to render the scene twice for the light buffer applied to geometry but it really allows to have 300 moving lights at 200 fps on a 3 years old card. The original Doom 3 renderer was like 15 fps. The only downside is that deferred shading approaches are only a win for non-shadow casting lights. Wolfgang Engel also supplied some ideas for massive shadow map rendering but I never invested enough time to understand it.

 

 

How does this compare to what is being done in BFG?

 

From what I can tell, it's still an immediate mode renderer but appears to have 3 shadow methods?

 

I can't say too much on the BFG renderer yet. It does not run in the main thread with com_smp 1 and it uses parallel jobs in the renderer frontend for adding lights and models.

 

It is a lot faster than the original Doom 3 in testmaps/test_lotsaimps.map. However my old renderer has the same speed with shadow mapping and without any multithreading.

 

So, when he eventually uploads it, Tr3B's renderer will be as fast or faster than BFG but will be closer to the regular Doom 3 code-base. Still, I am pretty sure he did not implement GPU mesh deforming so the BFG code might serve some use eventually if someone can possibly port that portion.

[lost_soul]

BFG edition (already) ported to Linux!

 

http://www.phoronix.com/scan.php?page=news_item&px=MTI1NzE

[nbohr1more]

Robert B from your article is Tr3B. Or at least he posted the same Github repo as his own at D3W. The nice thing about his BFG build is that it is setup to compile with cmake. Really wish they wouldnt take swipes at Doom 3 over at Phoronix.

[pelvis_presslays]

Robert B from your article is Tr3B. Or at least he posted the same Github repo as his own at D3W.

 

Yes, Tr3B == Robert Beckebans

 

He's the man behind the former (awesome) XreaL project (

), forked off the GPL Quake 3 (or ioquake3 ?) engine with a brand new modern OpenGL 3.x renderer and ability to load Doom 3 assets, and his new ETXreaL project.

[Baddcog]

Don't know if anyone still need it...

 

 

Doom3/resurrection pack is on sale on Steam today/tomorrow.

 

$3.24

[nbohr1more]

Not sure if this makes a difference for the possibility of code porting but Jmarshall got BFG to work with mods:

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=39&t=26065

 

 

I might just pickup BFG edition to see how TDM 1.06 runs on this...

[motorsep]

I don't know if anyone here investigated BFG Edition, but I have and I can tell you that it's not moddable. The workflow of authoring mods / new content is totally different and tools that you need for that are missing. It's _much_ faster than original Doom 3 at rendering many enemies with dlights (read Imps), so potentially one could have Doom like feel to it, with crowds of enemies. Oh, and the way resources get packaged, you get massive duplication of content. That's why BFG takes ~8Gb on HDD. Oh, and old menu code is not there, so you would need to buy Adobe Flash or get Flex SDK to author swf menus. Not to mention there is no documentation whatsoever on that subject (how to interface SWF with scripts in the game).

 

While BFG is very interesting engine, optimized and fast (thanks to multi-threading), BFG in its current state is no use for modding.

[Serpentine]

We're not looking at it really, sometimes I check if they've fixed a bug or something... but nah, it's not being looked for anything besides reference.

[nbohr1more]

I figured as much.

 

I didn't know if Jmarshall changed the material parser in this version to allow traditional

Doom 3 ascii formats. (Otherwise how would this allow mods to work? Unless only "new" mods are applicable

here?)