stgatilov

This is (or soon will be) not an option, if you want to avoid the issue when an item is frobable but does not highlight at all.

Wow, sparklies! Yes, bloom is applied after outline, and most likely it will remain so. You can set "r_frobOutlineColorA 2" instead of "r_frobOutlineColorA 5": the outline will still look hard, but I don't get these uberlights on highest bloom settings. It can be fixed properly of course, allowing to reduce r_frobOutlineColorA down to 1, but that would need code fix.

It seems frob outline does not work in old backend right now.

The latest build dev16368-9627 contains a lot of changes in how frob outline/highlight works. Moreover, the outline is enabled by default again... but not the same one as before. Now there are two different implementations of frob outline: Image-based outline is the old one (r_frobOutline 1) --- was default previously. Geometric outline is the new one (r_frobOutline 2) --- currently set as default. Note that the image-based outline works a bit differently than before: there were fixes for alpha-tested surfaces, depth fighting issues, translucent objects. Both of the implementations have some strong and weak points, and it's not clear yet which one suits TDM better. Cons of image-based outline: Outline has to be thick. Some visual artefacts due to depth test conflicts. Cons of geometric outline: It does not fully support alpha-tested surfaces. Soft version has intensity bumps at mesh vertices. To simplify testing, there are three presets which can be enabled easily: r_frobOutlinePreset 1: hard geometric outline (set as default for now) r_frobOutlinePreset 2: soft geometric outline r_frobOutlinePreset 3: image-based outline Here r_frobOutlinePreset is just a command, which sets a bunch of cvars to proper values. All three presets respect depth. The old frob-related cvars should still work as they did, in case you want some fine-tuning. You can also change thickness of geometric outline via cvar r_frobOutlineExtrusion.

New version is available: dev16368-9627

Yes, I suppose using the code from original Doom 3 is a better option for us, in case they are different.

I think there are no hard limitations in the engine, just things become slower as you push more data. Most importantly, the engine uses stencil shadows, which requires processing meshes on CPU. Shadow maps mode is also available, but it is up to player to choose between them, and some lights will use stencil shadows anyway. As far as I know, there are general guidelines for texture sizes and polycount in TDM, I hope someone will post them. Note that TheDarkMod does not have physically-based rendering, hence it might be hard to make scanned objects look exactly as they do in real life, especially under various lighting conditions.

I created an issue: 5772 I tried to fix it quickly, but it did not work out...

Is there any simple/quick way to reproduce? Maybe some existing FM? test map?

Compress it with zip or 7z, it should become much smaller.

"Changing driver" is not the same as "replacing DLLs manually". "Replace DLLs manually" means: you download DLL with that name from Internet, then hunt down all places where DLL with same name exists on your machine, and replace the file everywhere. I guess your system will become more and more broken if you do so... "Change driver" means go to official website of hardware vendor, find where you can download drivers compatible with your hardware, download it. It should exist as some kind of installer (usually some .exe file or .msi, e.g. win64_15.33.53.5161.exe), which you can run. Usually it shows you some dialogs like "Hello, I'm going to install Intel HD graphics driver", maybe even some options. Another way: open "Windows Device Manager" with admin rights, find your video device there, open its properties, go to Driver tab and click Update driver button. Although this way perhaps you'll only get drivers approved by Microsoft, which are not necessarily the most recent ones (not sure). So, which way did you use?

Well, if you did it by replacing DLL files, then it's not surprising.

Yes, but unfortunately I often lose debug settings either after config wipe of because I was checking performance and thought that debug context might affect it (although I'm not sure debug context has any performance consequences). I hope you see these messages on 2.09a or latest dev build, but not on the latest code SVN?

According to this page, your driver was released in 2014. And the new version you write about was released in 2015 according to another page. Here is the page for discontinued Intel graphics cards: https://www.intel.com/content/www/us/en/support/articles/000005733/graphics.html And it has an entry Intel® HD Graphics 4000" page, which references the page for the latest driver: https://downloadcenter.intel.com/download/29969/Intel-Graphics-Driver-for-Windows-15-33-?v=t The driver there has version 15.33.53.5161, released in 2020. That's much newer than what you have. Of course, you have a special monitor, and maybe not every driver fits your case.

Also, please try to record a crash dump as described here: https://wiki.thedarkmod.com/index.php?title=Save_a_Memory_Dump_for_debugging_Crashes I think it should be as simple as going to Task Manager and right+click + create memory dump on TheDarkModx64.exe, while the error message that you posted here is still being displayed. If I have a crashdump, I'll be able to see what the game was doing at the moment of crash. In most cases it gives a lot of information about the reasons of the crash.

Under which exact circumstances does the game crash? Does it crash before you see loading screen, while you see it, or after you "click attack to start", or somewhere in game? Does it happen on New Job mission? The condump that you attached does not witness the crash itself. It would be great to get condump with everything up to the very point of crash. The only way to achieve it is to open Darkmod.cfg, find the line with logFile, and change it to seta logFile "2" (UPDATE: it seems it is already set in your config file). Then run the game on New Job FM and reproduce the crash. Then find the log file at fms/newjob/qconsole.log.

No idea, but I'd advise strongly against replacing driver DLLs directly. If you think it's too dangerous to install new driver, then there is nothing else to do here.

When you are stepping through R_InitOpenGL, there are some calls to other functions. If you are doing "step over", then you skip what happens inside. But for some functions, it might be worth to "step into", because the reason why you see the error might be there. Anyway, I have reviewed the code, and I think there must be some message/warning in console in case of OpenGL initialization failure, which says what went wrong. If you still have that bad config file, could you please reproduce the issue again and see what's printed in game console? Perhaps you'll need "logFile 2" for that. Also, I have changed the so-called "safe mode" in svn rev 9613. When renderer cannot initialize OpenGL with user settings, it reverts some of them to basic values which should always work. Previously "safe settings" were fullscreen with non-specified width/height, which is not safe at all Now it is 800 x 600 windowed mode, which should be the safest to set up. So if you update from SVN, build TDM and run it with bad config, you should get 800x600 window and some warnings in game console instead of fatal error.

I fixed that. Please update from SVN and try again.

I'd say removing darkmod.cfg is also worth trying.

The faulty module is Intel's OpenGL driver that is installed in your OS. First of all, try to update your graphics driver. If it does not help, I think two things can help: Condump, obtained with "logFile 2". Crash dump recorded by Windows. Both things are described on the wiki page.

Yeah, #include <limits> is needed at the beginning of the cpp file.

You can also try to comment out the following lines in CMakeLists.txt: add_precompiled_header(TheDarkMod "idlib/precompiled.h" "idlib/precompiled.cpp" "precompiled.h" EXCLUDE "game/gamesys/TypeInfo.cpp" "idlib/Token.cpp" "idlib/bv/Frustum_gcc.cpp" "sys/win32/rc/CreateResourceIDs.cpp" "ThirdParty/artefacts/tracy/src/TracyClient.cpp" ) Just put # (sharp) at the beginning of every line. Perhaps it would change something...

Take the latest revision from SVN trunk: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk/ Put it to darkmod_src directory. Take the latest dev build from tdm_installer. Put it to darkmod directory nearby. UPDATE: Perhaps you don't even need assets, since everything fails very early. Open darkmod_src/TheDarkMod.sln in Visual Studio. Select Debug With Inlines and x64 configuration, build solution. Find function R_InitOpenGL, set breakpoint at its beginning. Start With Debugging (usually F5), and after breakpoint hits, go step by step (Step Over). You'll probably have to go inside GLimp_Init (Step Into) to see what failed there.

You should also do svn revert, then look at some of the headers from the error message, and verify that it contains text. Than start build. Then look at the header again: does it still contain text?