Doom3world

HELL YEAH!

https://twitter.com/ID_AA_Carmack/statu ... 1369502720

Very nice move. Much appreciated.

Hopefully the "third party bits" aren't huge parts of it which are hard to replace.

I'm guessing Steam integration, Bink video and stuff like that.

I was thinking everything console related actually.

Awesome !!! Best news one can get while sitting under palmtrees in the pacific...

Next Mai Thai drink is for John & Brian

The big question is if multiplayer part is back portable to Doom 3 GPL. If it is, it's cool. If not, it sucks.

I wonder if D3BFG uses GLSL. Can anyone check the console?

Also, if D3BFG uses strictly C++ for gameplay logic, then it's going to be tough to mod :/ And ofc there is no Linux / Mac support. Nor any tools.

So, I only hope certain pieces of the code can be back ported.

Us Source modders have been compiling cpp gamecode into DLLs for years. It's not tough, but true, it's more difficult to jump into than .script files. Though I don't know if BFG compiles it into the .exe or an external file(DLL).

If anything it's better... I mean, does idtech 4 have a nice application to write your scripts in? With cpp;
-Faster(it's compiled and optimzed)
-TONS of tutorials and books
-TONS of people know it
-VirtualStudio(there are others as well)
--auto-complete
--When compiling, will display errors, performance warnings, etc.
--Organizes all your files

I bet I'm forgetting some more...

And yet, no "tons" of mods. Quake was popular modding platform (and still is) because QuakeC is one of the easiest scripting languages to learn.

Also, I don't see how Source modders correlate with Doom 3.

So yeah, modding for masses requires DoomScript, modding for obscure number of gurus can go with C++ just fine. In other words, C++ doesn't help accessibility and popularity.

Mind you, right now nothing stops Doom 3 serving both groups of modders. But going C++ only will kill it for masses.

Anyone know if it has updated netcode?

This is pretty awesome news for people that want to develop for the rift headset- a high framerate engine with the integration done by Carmack, who's been doing headset work for quite a while.

I'm pleasantly surprised.

How can one develop without tools?

As far as I am aware it is using idtech5 netcode which should be less vulnerable to latency compared to D3 1.3.1

Too bad my copy is arriving at home while I am still on holidays.... can't wait to run the server/clients through the network emulator testing it under high network latency and jitter conditions...

How back-portable would that be? Afaik idtech5 is quite different from idtech4 (code base specifically).

There is a quote in the other thread that they moved the gamecode into the exe because using dll-s would have made development more difficult on the consoles.

The gameplay netcode, which is the bit that has the latency issues due to the snapshot rollback/repredict, should be back portable. I think we'll see relatively few other changes to the gamecode parts of the source once it is released (ie base, d3xp).

The scripting system is still present. The structural change was to bring the already compiled gamex86 dll code into the exe rather than being dynamically loaded at runtime.

I'm going to extract all resources today and build a 'same', 'changed', 'added' and 'removed' list.

There are a ton of New GLSL shaders in there.

Edit: for anyone interested, the bfg code is VS2010 as with the original release, so we don't have to jump ship to 2012 just yet.

I bought 2 copies of the Doom 3 BFG Edition to support id Software and after that I saw this news. Really great.

I did some research on the new renderer and it seems like that there are more changes than I expected. First of all it is a OpenGL 3.2 renderer and it seems to have a single mixed ARB/GLSL mode.
It also has some interesting features that were not part of the Doom 3 GPL release like skeletal animations accelerated on the GPU (r_useGPUSkinning).

The Doom 3 BFG edition has no cool way to compile shader permutations like XreaL or other open source games. That causes the high number of GLSL shaders. e.g. if you have an interaction shader for lighting and you allow GPU vertex skinning then you need different vertex shaders on different model types (static or skeletal) which duplicate a single shader for each model type. So the GLSL shaders are more or less standard stuff for Doom 3 style rendering with GLSL except the stereo rendering.

However it is also nice that the deprecated fixed function stuff was replaced. So Doom 3 used an ARB shader for lighting but the fixed function pipeline of OpenGL for fog lights.
It seems to be all unified like an OpenGL 3.2 renderer requires it.

From a quick view I can say that it is some nice work.

Not to spoil the party and all, but still waiting for some other stuff that was promised in the past.
See it, then I'll believe.

Does it mean ARB2 shaders are still in use (meaning we wouldn't have to re-create our shaders in GLSL) ?

There is for every ARB shader an equivalent GLSL shader. It might be possible that the old ARB shaders aren't used anymore.
They shouldn't work if it is a "pure" OpenGL 3.2 renderer as ARB shaders are deprecated. However it is possible to run OpenGL 3.2 in a "non-pure" context with the deprecated stuff enabled.
I can't say it from looking at the console log.