dhewm3, a 64bit native doom3!

[etdarkb]

Do anyone tried (or is willingly to try) this doom3 source port?

 

https://github.com/dhewm/dhewm3

[Serpentine]

Yeah I've played with it quite a bit. It's also got some nifty stuff that I've been porting over to TDM.

 

That said, dhewm3 will run slower than the gpl release for a number of reasons, so other than letting you use a bunch more memory and avoid needing 32bit support in your OS... it's not going to blow you away. Mostly the port is about portability

[chakkman]

I started to play through Doom 3 again a few days ago, with a pre-release version of dhewm3, which allows for higher framerates than 60 FPS (playing on 180 Hz here). Fantastic. As in most games, the higher framerate really makes the game more enjoyable, as everything looks so much more realistic, and feels buttery smooth.

[revelator]

been working with the developer towards adapting a few more TDM functions like support for newer cpu models, uncoupling of the framerate (looks like he finished that one himself) and maybe somewhere down the road a GLSL based renderer plus shadowmaps. sadly my time is stretched all over the place atm due to illness in the family so i havent had time to do more work on it.

one gripe people had with the port is that it is not compatible with the GPL build mods though most of them have been ported now so its mostly just a problem if the modder newer released his sources.

[chakkman]

The version I'm playing is pretty issue free. I read that there are some physics related issues with the unlocking of the framerate, but, I haven't really noticed anything. 

One thing I'd still like to see is improvements in the audio quality. The BFG Edition of Doom 3 has fantastic sound. Not sure what they did there (probably something with the dynamics), but, it's much better than in the original Doom 3 and in dhewm3. 

Edited October 26 by chakkman

[revelator]

probably needs some fine tuning , not sure if the BFG versions uses the old openal SDK or was updated to the openalsoft version also ? might explain some of it i reckon.

i do have a version of dhewm with atleast some of the mentioned GLSL functionality (interaction shaders for now).

It uses a hybrid GLSL/ARB renderer and works quite ok on my own port but ran into a few snags with dhewm3 cause it uses a hack for enabling hardware gamma with SDL3 which bypasses the code used for splitting up the hybrid renderer between ARB and GLSL parts. So gamma is broken in SDL3 builds until i can get a GLSL version of the shader used.

sadly thats a bit beyond me  as i come from the C world and only started to learn some basic C++ due to the release of the idtech 4 source code. And i newer really got my feet wet with hardware shaders.

[lowenz]

BFG->XAudio

Same for RBDoom3 BFG (as default)

Edited October 26 by lowenz

[revelator]

oki so no openal at all then. guess the xaudio implementation is really good .

openal seems to be a bit over the top on some effects like 3d audio where it sounds like your standing in a concrete tube with echoes to max. could probably be toned down if someone with a good ear took the time to adjust levels.

[chakkman]

3 hours ago, revelator said:

probably needs some fine tuning , not sure if the BFG versions uses the old openal SDK or was updated to the openalsoft version also ? might explain some of it i reckon.

All that I find about it is this:

• EAX enhanced sound quality removed

I remember the sound from the BFG Edition not only louder, but also more full/bassy. Maybe I'm wrong, and it's just louder, thus "better".  

[revelator]

Could be ?. What many dont know is that openalsoft can be configured with a simple config file in the same directory as the dll "alsoft.cfg". There are some hints on the net on how to finetune openalsoft if it acts up. There was also some bug with the emu10k driver atleast on linux at some point which caused a lot of problems, but chances are high that this has been fixed in the latest version. Openal was sadly not the easiest sound engine to work with, mostly due to it being a low lvl driver like opengl32 / vulkan etc.

[revelator]

hmm i think linux builds of rbdoom3bfg still use the openal-soft backend due to not having access to xaudio (besides running it in wine). i just experimented a bit with alsoft-config.exe which is a qt6 gui for openal-soft. sadly while it does work on windows it is clearly geared towards linux as the only backend with any semblance of control over the runtime is pulseaudio. it does have a plug for wasapi but the only setting it can control is the resampler and it only allows on or off lol.

so for more fine grained control on windows one would have to read up on openal-softs config files and what settings can be used in them and then write those by hand ugh...

jack is also supported but thats another backend not native to windows so .

could ask if daniel would support xaudio as an alternative on windows but i wouldnt hold my breath on that one.

[revelator]

hmm its actually rather advanced and unfortunatly a bit of a pain to setup.

one example is hrtf (headphone surround) which requires mapping sound locations with a tool they provide.

https://deepwiki.com/kcat/openal-soft/5.3-gui-configuration-tool lists a good deal of which steps needed.

for all other cases it is probably better to ask on the github forums for it.

attached my own config for dhewm3 which sounds somewhat ok. drop it next to the dhewm3 executable.

if you feel up to experimenting you can add your own settings to it 

alsoft.zip

[revelator]

hmm another small problem creept up from behind when doing SDL3 builds. SDL3 removed the old hardware gamma ramps from the library so dhewm uses a shader based version. unfortunatly for my hybrid GLSL/ARB interaction renderer it only works in ARB mode because it is hacked into the interaction shader stage instead of the material shader stage and sadly i do not have an implementation of this hack in GLSL . I have a rough idea how to do it but i lack some skills in regards to working with hardware shader code.

i do however have an old codepiece which i used in quake as a replacement for the old gamma ramp code but it needs a little work. what it does is actually really simple, it uses the same code as overbrights but scales the output with the gamma value. also overbrights tended to use a texture this code foregoes that completely as it is unneeded and instead outputs to a fullscreen quad. it works somewhat good in quake but there are two values in dhewm brightness+gamma so i might have to get creative.