id Tech Forums

https://github.com/id-Software/DOOM-3/blob/master/neo/sys/sys_local.cpp#L123

@motorsep:
nope. VR support would be nice to work on, but i am not planning to invest in a VR headset any time soon, sorry ;(

@grml4d:
Updating the sound backend  to get rid of the old EAX stuff is on my ToDo list.

Yes, i am well aware of the fact, that some of those libs are pretty old, but they still compile and work just fine (only some minor tweaks for VS2017 were necessary).
I don't consider them a security risk, they are totally irrelevant performance-wise and they are only used very
occasionally in the engine (jpeg only for loading roq videos, curl only for downloading assets, so nothing really important).
Currently there is no point in updating them.

The only exception to this might be curl, because the linux version is currently build without it. I will probably update curl and integrate it when i look into the networking part.

wow! over one year has passed since the previous fhDOOM release. RL and other projects kept me very busy, so things became a bit quiet around it. After several requests from different people, i released a new version a few days ago:

http://www.facinghell.com/fhdoom/fhDOOM-1.5.2-1414.zip

This release contains mostly bugfixes and internal code changes. There is other stuff in the pipeline that is more visible and more relevant to the game, but i don't want to delay this any longer.

• fixed ambient lights (thx raynorpat for contributing some code!)
• fixed black objects: some objects (mostly rag dolls) appeared completely black until beeing moved the first time.
• unified texture loading   
  
        
  • all texture loading (uncompressed textures, compressed textures, cube maps, image programs) goes through the same code path
  • all textures are now immutable
  • added support for cubemaps from dds files
  • added support for RGTC/3Dc-compressed normal maps
  • channels (red/alpha) of tga normal maps are no longer swapped at load time
     
• fixed several effects for RoE (some things are still missing for full RoE support, but at least its playable now)
• improved linux support
  
        
  • fixed core profile context
  • fixed several compilation issues (compiles now fine with gcc 6.2 and clang 4.0)
  • fixed some keyboard layout issues
  • added shell script to install required build tools on an ubuntu system
     
• fixed light/shadow flickering (in certain scenarios everything in a lights range seemed to be completely shadowed or not, depending on your view point and direction)
• fixed vid_restart, reloadEngine and loading of mods
• fixed a few minor issues with Visual Studio 2017 (compiles now fine with VS2013, VS2015 and VS2017)

HF!

send me (via PM) full examples (map, materials, shaders, textures, etc.) for ARB and GLSL version and i will take a closer look at.

from time to time i take a look at the forum.

don't look at heathaze.fp to learn how to port ARB to GLSL, because heathaze.fp is not a straight port.
heathaze.fp was the very first shader i re-wrote and i experimented a lot with it. The current version achieves a very similar effect, but is implemented differently.

IIRC heathazewithmaskandvertex is much closer to the original ARB shader.

It's hard for me find any time for fhDOOM at all, so i probably won't look into the details of your fresnel shader any time soon.
A few things i noticed after glancing over your GLSL:
* R1 and others are indeed undefined, you probably meant result.R1
* output of vertex shader and input of fragment shader must be equal (look at vs_output)
* R1, R2, etc. should be temporary values ('R' for register), you only need them in your vertex shader (don't pass them to fragment shader)

the new shader system is pretty much undocumented. I could write something up, but it won't help you very much when you are totally new to writing shaders. Writing shaders is not that trivial, especially with an engine like idTech4. The whole shader thing is pretty much hacked on top of Doom3's fixed-function-style material system. The shader system is not that cleanly designed and integrated like in a more modern engine.

Quote from: argoon on November 06, 2016, 10:02:30 PM
Hey eXistance if you are still around can you tell me if is possible to disable your new shadow maps by material or by script like we do with the old stencil shadows? It seams the noShadows global material keyword is ignored by shadow maps, i'm sure you did that so alpha tested materials on the vanilla maps could cast shadows but, i found on my testes with a custom grass/LOD system that a bunch of grass planes casting shadows is not good for performance. 

Yes, your assumption is correct: the noShadows material flag is usually* ignored on alphatested materials to enabled shadows. There is currently no way to enforce noShadows on materials. I will probably add support for something like force noShadows to the next release of fhDOOM to fix this.
Can you create a func_static from your grass planes? Setting the entity property "noshadows" to "1" should work fine.


*: there is a dirty little exception: if the material is alphatested, but is not two-sided and the name starts with "texture/decals", the noShadows flag works like before. I guess that won't help you very much...

Quote from: EmoLevelDesigner on August 27, 2016, 06:34:31 AM
If a game supports 144Hz and motion blur it plays a lot better than just fine or pretty nice. It becomes like a window into another world. 144Hz together with motion blur eliminate immersion-breaking lights and fires that magically start to blink when you look around and fast moves that lose smoothess due to being too quick.

144Hz is better than 60Hz, i won't argue that. As a test i already bumped the limit to 120* and it doesn't feel that different, so i still believe it's not worth it (for Doom3).
Hitting 60Hz on older hardware is hard enaugh and there are more interesting and more important things to do (for me as a dev and IMO for most users as well)

* the limit also affects other things like networking, so i don't want to release it that way.

the engine usually treats them just like other textures/materials.

common/caulk is not special, it is just defined in such a way (see invisible.mtr), that the dmap compiler does not generate visible geometry for it (so the renderer does not know about it).
But it still seals the levels and generates collision geometry.

common/nodraw is similar, just look at its definition.

Hi,

Quote from: EmoLevelDesigner on August 23, 2016, 11:27:53 AM
Do you plan to implement support of high frame rates? The game would be a lot more immersive if played at 144fps with motion blur.

60Hz is IMO just fine. Even DOOM (2016) which is a lot faster than Doom3 plays pretty nice with 60Hz.
I have currently no plans to implement motion blur.

Quote from: EmoLevelDesigner on August 23, 2016, 11:27:53 AM
I like it so far and look forward to newer version with more optimizations and bug fixes. For testing if everything in the port works properly I would recommend this map:
http://doom3.ru/news.php?id=1350
Link to download: https://disc.yandex.com/d/UWCr_8rinXwWf

I believe it would serve well as a stress test because it has a detailed open area with many shadows, buildings you can enter. Also while testing you can enjoy new innovative environment in Doom3 universe - artificial terrain carved by martian civilization. There are buildings, stations and cargo trucks of UAC origin you can enter, they have original architecture too, and challenging battles will push your skills of opposing the demons to the limits and beyond.

Thx for the suggestion, but i don't think this map qualifies as a test map.
* a lot of things are just bad for performance (even for original Doom3 and stencil shadows)
* it looks pretty amateurish
   * low-poly brush-based terrain
   * simple lighting
   * simple texturing
   * missing details in general
   The map has some pretty neat ideas and i really don't want to bash it, but it's just not on par with the maps from the original game.
* everything is russian? WTF? i don't undersand a single word of it...

I am focused on the original game. That beeing said, i have same ideas for a little demo map designed specifically for the improved engine.
Unfortunately my time is very limited right now, so progress on fhDOOM is slowed down at the moment ;(

Windows for gaming and most professional and personal work (just switched from Windows 8.1 to Windows 10). Everything i need just works, driver issues are very rare and most users/customers are windows based anyway.
There are a few things that annoy me from time to time, but overall it still makes me more productive and i can focus on the stuff i want to get done.

Linux for servers and for some scientific projects (my university is mostly unix).

Quote from: EoceneMiacid on June 29, 2016, 12:19:50 PM
Hmmz, I ended up on the Facing Hell website which clearly states that somebody with both your real name and your nickname is the lead level designer for the project.

What are the odds huh

I might have known it. That project is dead since ~10 years or so, there is no work being done on it

Quote from: EoceneMiacid on June 29, 2016, 12:19:50 PM
Well, for now, I guess I have little choice but to leave it.

Thats very understandable and i am totally fine with it

Quote from: EoceneMiacid on June 29, 2016, 12:19:50 PM
I'm honestly not trying to guilt-trip you here, but the lack of an industry standard Doom 3 source port across all OS's is at this point probably the largest obstacle to growing our numbers.

I always thought of dhewm3 of beeing exactly that, since it stated on the github wiki: The goal of dhewm 3 is bring DOOM 3 with the help of SDL to all suitable platforms.

I am not working on a mod project.
Mod support is still there and fully functional, you just can't load dll/so files that have been compiled for vanilla Doom3 1.3.1 (but thats for true for dhewm3 as well, afaik).

It's not the jack-of-all-trades-uber-idtech4 engine that some seem to expect. It's just a personal research and learning project, and i have said that many times.
Sorry, but that's the way it is. I am tired of explaining myself for that. Take it or leave it

@0x29a(and @bitterman to some extend):

It's not possible to integrate SikkMod's (ARB2-based) interaction shaders into (GLSL-based) fhDOOM, you simply cannot mix these things. Some of SikkMod's (ARB2-based) post processing shaders might be technically capable of being integrated into fhDOOM, but i am not sure about that. Even if it is possible, i would need to put an uncertain amount of extra work into fhDOOM for that, drop OpenGL core profile and probably apply some changes to SikkMod's shaders. I simply don't want to take that route, especially because all those changes have to be maintained and i fear that this kind of backward compatibility hinders future changes.

Playing with a couple of new rendering features is next on my ToDo list and some of those features are implemented in SikkMod as well. I already did something like that with Parallax Occlusion Mapping. POM in fhDOOM is not ported from SikkMod, it's the same feature just implemented from scratch in a more modern way (but it suffers from the exact same problems, that's why it's off by default and the option to enable it is not exposed in the game's main menu). A future release of fhDOOM might suit your needs better, but don't count on it. If you need SikkMod you are stuck with vanilla Doom3 (or dhwem3?).

fhDOOM was never meant to replace one of the existing engines or revive Doom3 modding or something like that. I never cared very much about these things (i even dropped support for mods of the original game, that alone is a huge disadvantage compared to vanilla 1.3.1). fhDOOM is tailored to my particular needs and interests.

@EoceneMiacid:

Linux is supported, but since i am currently focussed on Windows, the linux build is not maintained very well and the game is not tested regularly on linux. I did a quick test on a fresh Xubuntu 16.04 (64bit) machine yesterday and it compiles and runs fine (at least with proprietary nVidia drivers, not sure about the different AMD drivers). See http://www.facinghell.com/fhdoom/fhDOOM-1.5.1-1413-linux.png Keep in mind, fhDOOM is still 32bit only at this point. So if you are on a 64bit machine, you need to install 32bit versions of some libraries. Better linux support is on my ToDo list, but priority is very low.

Here is a crude little script that i use to install all dependencies on an ubuntu machine to compile fhDOOM:

#!/bin/sh
# installs required packages on Ubuntu to compile fhDOOM.
# most packages will install additional dependencies that are also required but are not explicitly listed here.

echo "installing basic stuff..."
sudo apt-get install git cmake g++

echo "installing dev packages..."
sudo apt-get install freeglut3-dev libalut-dev libasound2-dev

MACHINE_TYPE=`uname -m`
echo "machine type:"${MACHINE_TYPE}
if [ "$MACHINE_TYPE" = "x86_64" ]; then
echo "installing 32bit libraries..."
sudo apt-get install g++-multilib freeglut3-dev:i386 libalut-dev:i386 libasound2-dev:i386
fi


Hi,

I worked on a couple of things over the last weeks (mainly related to AMD and performance)
and i think it's time for a new release for those who are interested.

download: http://www.facinghell.com/fhdoom/fhDOOM-1.5.1-1413.zip

changes:

• AMD texturing issues solved (r_amdWorkaround is gone)
• Lots of performance improvements
  
   
  • optimized draw calls and state changes
  • use a 4k*4k dynamic shadow map atlas to batch shadow maps
  • modified dmap to generate optimized occlusion geometry for shadow map rendering
    
         
    • occlusion geometry is stored in a separate *.ocl file (*.map and *.proc are still the same)
    • ocl file optional, maps without ocl file work just fine (at the expense of performance)
    • dmap option 'exportObj' will export occlusion geometry to obj files (i needed that for debugging, not sure whether it is useful to others)
    • fhDOOM release includes ocl files for all maps of the original game
  • more aggressive culling
  • performance improvements are huge on AMD (on nVidia the improvements are not that significant, but still noticeable).
• fixed (time)demo rendering
• implemented shadow mapping for parallel lights
  
   
  • uses cascade shadow maps
  • not final, there are still some things to improve (flickering, light bleeding)
• improved shadow filtering
  
   
  • poisson filtering
  • softness is constant across the light range, making shadows alot easier to tweak
• fixed some smaller editor issues
• changed required OpenGL version to 3.3 (core profile)
  
   
  • will not necessarily stay at 3.3, future releases may require 4.x again (depends on what exactly i will work on)
  • still requires GLSL extension "GL_ARB_shading_language_420pack" (should be available with all modern drivers even on older hardware, at least on AMD and nVidia)
• added soft-particles and soft-shadow-quality options to main menu
• removed cvars:
  
   
  • r_amdWorkaround
  • r_smQuality (replaced by r_smForceLod)
• new/modified cvars:
  
   
  • r_smForceLod (same as previous r_smQuality, forces a certain lod on all lights)
  • r_smLodBias (increase lod on all lights)
  • r_smUseStaticOcclusion (enable/disable static occlusion geometry from ocl files)
  • com_showFPS (0=Off, 1=FPS, 2=ms, 3=FPS+ms)
  • com_showBackendStats (show various backend perf counters)
  • g_projectileLightLodBias (reduce shadow quality from projectile lights, usually not noticable)
  • g_muzzleFlashLightLodBias (reduce shadow quality from muzzle flashes, usually not noticable)

I did all the development with an AMD Radeon HD6950 (CPU: Intel Core2Quad 2.8GHz). The AMD Gaming Evolved App ("Raptr"?) causes a significant performance drop, so i recommend you disable that before starting fhDOOM.
At highest quality settings, there are still some scenes where framerate drops below 30FPS ;( Changing shadow quality to medium (via main menu or r_smLodBias 1) improves the situation a lot. Can someone with a modern AMD card verify this?

There are still some things i would like to implement to improve performance, but right now i am a bit tired of it. There are a couple of new features i want to test out and few more content-related things i want to try out, before eventually getting back to performance.

Feedback appreciated

@oneofthe8devilz
@SteveL

Shadow mapping for parallel lights is on my ToDo list and i am aware of trebors implementation.
Right now i am focussed on performance (especially on AMD), cleaning up a lot of things and fixing a couple of bugs.

@argoon

No, i will not switch to dhewm3 any time soon.
I tinkered with the idea of updating the sound engine as well, but it's very low priority right now.


@nbohr1more

Thx for the hints! I remember some GLSL-related work on Doom3 from Pat Raynor a few years(?) ago, but totally forgot about it.