stgatilov

"Frontend acceleration" is the user-side name of cvar r_useParallelAddModels, which controls job-based parallelism inside frontend. And cvar com_smp controls the original two-thread parallelization which was present in Doom 3. We used to have a troubleshooting switch for it in the menu, but later we deleted it because this parallelism seemed stable enough. If you are interested, it is described here: https://wiki.thedarkmod.com/index.php?title=Tracy:_timeline_profiler#Gameplay

I have updated this section of wiki about crashdump analysis: https://wiki.thedarkmod.com/index.php?title=Analyze_a_Memory_Dump#Get_debug_symbols We treat debug symbols exactly the same Windows way on Linux. I save debug symbols for ~10 last dev builds/betas locally, and they are also saved in assets SVN (not public) for main releases. I can give them to anyone by request. Historically, crashdump analysis was not very popular activity, although it is very easy on Windows side. Anyway, the crash is hopefully fixed in the engine now: 6510 (will get into the next dev build).

Try this: https://wiki.thedarkmod.com/index.php?title=Save_a_Memory_Dump_for_debugging_Crashes#Record_with_GDB UPDATE: Finished that section. Along with instruction on how to analyze a core dump.

Can someone share stack trace of the crash or a core dump?

Parallel image loading only happens when level is started. In this case a shader is compiled during gameplay probably. I think we have some issues with it. Maybe shader compilation starts on non-main thread. And then depending on the driver/OS it can result in anything... UPDATE: For some reason, shader compilation does not happen at all for me when I teleport to and frob atdm_loot_painting_medium_4. The shader is loaded during level start regardless of any conditions, which is the right way. And I see no crash inside VM.

Changelog of 2.14 development: dev17330-10984 * Tonemapping is now applied to game frame only, HUD and menu are not affected. Includes major & breaking changes in X-ray implementation (6606). * Now engine defines macros TDM_VERSION/TDM_REVISION/TDM_VERSION_FULL in game scripts and GUI. * Added all missing mipmaps in DDS textures (post). * Fixed crash from having many localization packs (6611). * Fixed comments parsing and automatic collision model for OBJ models (6610). * Ported some fixes from dhewm3 repo: save/load, snprintf, bad memset, some RenderSystem shutdown fixes. * Fixed number = 1 in inventory GUI on non-stackable items (thread). * More fixes in fonts (post). * Added cvar r_ssao_insubview which enables SSAO inside subviews. * Split oversized tdm_modelsXX.pk4 packages into more pieces. dev17332-10999 * Fixed Linux crash when material with custom shader is loaded during gameplay (6510). * Completely disabled old light estimate system (6546). * Now it is possible to use larger mesh models... at least static ones. * Ported some more fixes from dhewm3 repo: mostly warnings and uninitialized memory use.

The mipmaps are generated automatically when necessary. I believe there is some keyword which can block generation of mipmaps. In a sense, mipmaps is implementation detail. But DDS is sort of "engine-internal" image format, it works differently.

By the way, the 2.13 is finally released. I'd like to thank everyone for taking part in the testing! This is very important for making releases stable.

DDS is the only "special" format which has its own special code path. All the other image formats are read to produce RGBA 8-bit buffer on CPU, and after that their treatment is the same regardless of which format they came to (TGA/BMP/JPG/PNG / maybe I forgot something).

@chumbucket91, There are entity spawnargs, they start with s_, e.g. "s_volume". And there are equivalent sound shader keywords which look like "volume". However, "private" keyword is a bit special because it does not exist as spawnarg, it can only be set in sound shader. I did not see any in the code. But as @Daft Mugi noticed, there could be some changes because of the new way these settings interact/override between entity and sound shader.

Most of the shader stuff is about surfaces. For lights, it's only glprogs/tdm_lightproject.glsl, I think. And yes, now this chunk of code is duplicated in C++ code.

I looked into it with debugger. The mission_start sound shader does not run because it has "private" keyword, which means that only the entity which emits it can hear it. In your case "speaker_1" is the emitting entity, so player does not hear it. Now I see that only mission-related sounds have this keyword, and I wonder why is it even needed. I suppose it was necessary in Doom 3 multiplayer to make sure only local player hears some sounds he emits. But does it make any sense in TDM? Perhaps comment out all the "private" flags?

I think this is not exactly how it happens, because the algorithm is CPU-only, and it definitely works for invisible areas (e.g. guards detect bodies even if player is inside a locked room). But the issue 6546 and the aforementioned commit messages are a good place to start. Basically, the engine can now sample light intensity at any point at any moment, without any usage of graphical API. It computes all the shaderparms, conditions, settings, it uses raycasting to take hard shadow into account, it samples the light textures on CPU to take projection/falloff into account. Luckily, we only need consider to lights, we never touch surfaces. Computing surface properties on CPU would be unfeasible. The procedure is cheap for a single point, but very expensive for every screen pixel / mesh vertex. So just as you said, the meshes are sampled randomly, with samples distributed over short time. Some kind of average is computed. This spreading over time is unfortunately necessary to make results both fast and reliable. And this is the ugly part: if you request light value and use it the same frame, you'll just get zero. You need to continuously request light value of an entity in order to get meaningful value soon after you start. In principle, we can use this system to implement CPU-only lightgem (aka "weak lightgem" of the past). But its values will never match perfectly with the values of the current GPU lightgem, and I have a feeling that the switch might be traumatic due to behavior change.

I deleted the line.

Committed this fix in svn rev 17322. I suppose it used to work properly, but them some refactoring happened (maybe the one with "GUI size" settings), and this macro started to override proper visibility flags.