Doom 3 engine release and game code

[revelator]

Not unless ttimo applied those my source is based on his.
Checking non the less would be dumb not to.

[revelator]

Checking yup he applied it :S thanks for the fix.

Now you mentioned it i noticed that some models went black but i suspected myself bugging up some materials somewhere. im happy to know that i was not.

[revelator]

Hmm nice weapon ase models now look really good dunno if a side effect but it sure is visible.

[mh]

[motorsep]

Are those two bug fixes just for GLSL part or for vanilla Doom 3 ?

[mh]

It's mouse input, it's got nothing to do with GLSL.

[motorsep]

[mh]

That one applies globally; standard ARB2 as well. Not sure about ARB, but it should also apply to NV10/NV20/R200 as well.

[revelator]

Nice find MH thank you.

[revelator]

btw reverted the vsync stutter fix from jkriege as it makes the game go in slowmotion when fps < 60.
code needs a lookover but else i like the idea.

[revelator]

Atm taking a break but i hope someone picks up and add's newer or better engine code (im also interrested in helping with that).
Things that could use some updates of the top of my head.

jpeg code uses the now ancient jpeg6 source. It would be better to use the much more recent jpeg8 standard.
zlib code also ancient and contains security bugs.
curl ditto.
tga while it certainly works fine with the tga1 version it would probably be better to use the newer tga2 code (implemented in joequake as well as a few others i know of) supports many more types than the tga1 version and doesnt choke on topside down tga images.

defered renderer (must keep compatibility with doom3).
glsl some work allready done.
newer extentions (read up on ARB2 and it seems we got some stuff wrong ARB2 in later incarnations is capable of doing most of what glsl is "most of is litteral" i have this from SGI)
the problem is engine side as doom3 does not have the engine side interfaces for using stuff like ssao etc.
Support for larger outdoor areas (doom3 does an ok job when using megatexture but it does have its limitations and the megatexture version in doom3 is very old so updating it would certainly go along way).

While not perfect as many of the shaders use workarounds for missing interfaces sikk has shown that the doom3 engine can indeed be made to look like an engine for 2012 and with some work even further.

[motorsep]

I don't mean to be a party pooper, but here is OpenGL / OpenGL ES 2.0 port in active development https://github.com/omcfadde/dante

[toneddu2000]

I've to admit it: the idea to swicth from dp to doom 3 for my project is tickling me a lot! but I can't really understand now what's the future of doom 3 modified code. The link you posted, motorsep: is that version capable of accepting GLSL shaders instead of ARB ones?
It's very difficult for a non coder to find a way in this labyrinth of modified engines!

[revelator]

As posted above newer versions of opengl's ARB shader interfaces can do allmost anything the glsl interface can.
There are ofc edge cases but then its just a matter of implementing an interface for those in the idtech4 source.
I suspect the code could be speed up quite a lot by rewriting parts to do batch processing hmm.
Also add newer SSE interfaces for current gen CPU's might give some extra on modern PC's though i doubt it would bring much on platforms with opengl ES.

[motorsep]

OpenGL ES is the same as OpenGL + it runs on iOS and Android. That's what I've been told by the author. I don't get how ARB interface can be newer since it was not touched since GLSL came to be.

@toneddu2000: You don't need to be a programmer to figure out what fork to use based on maturity of the fork and features it offers If you go for Windows, stick with TTimo's branch. If you need to run your game and other platforms, and you are willing to give up original tools - use dhewm3 as it has SDL, 64bit, OpenAL and is cross platform (but totally incompatible with Doom 3 mods)