stgatilov

dev17376-11017 is available.

I don't know which Prey you mean and what exact reference is. If it is Prey 2006, then it was most likely mesh animations (e.g. geometry and texcoords). It is technically possible to do animated textures in TDM using huge piece of copy/paste with if-stage per frame, but it is hell to work with.

Just a few notes: It is sad we have not yet added proper support for animated textures Ideally, normal maps should match height maps, which you can't do without animation some textures. Walls breathing in would be better... positive parallax offset usually means more visible artifacts...

Unfortunately, there are two systems which work here, and they don't know anything about each other. First, there is a filesystem. It has a set of search directories (a directory can be pk4 archive too), which are sorted by some rules. You can see the sorted order near the beginning of the game console. If some file can be found in several search directories, then the file from the first directory wins. All the other instances are completely ignored, the game cannot see them at all and cannot know of their existence. Second, there is decl system. Sound shaders is one type of decls. One file often contains many decls. The order of loading decls from the files have nothing to do with the order of search directories in the filesystem. Recently I ensured that the files from missions take precedence over the core files, but the core-core and mission-mission ordering is still the same as in Doom 3, i.e. not something to rely on. As far as I see, the decl system enumerates all decl files, sorts them lexicographically, and parses one by one. Whenever it sees a decl with the name that is already occupied, it skips the new decl. So the decl from the lexicographically minimal filename wins (if both filenames are in core or both are in mission).

As far as I remember, yes. All the persistent info is carried through a single mission just as well.

This is not important actually, because missions are SHA-checked on download. It is important to get the listing of the missions with hashes via HTTPS though... but now the game gets it over HTTP. And tdm_installer is completely independent, but has the same problem. It verifies cryptographic hash for everything it downloads, but the download of the hashes should be over HTTPS, and it is not. At least all these important downloads always use TDM main server instead of mirrors...

Actually... a new user finds the installer link on the TDM website, and downloads it over HTTPS from the same domain. So it seems that verifying checksum does not achieve anything. On the related note, I started thinking that maybe I should add some SSL library to the installer and do at least critical donwloads over HTTPS. Theoretically, someone might intercept player's traffic and provide him different installation.

dev17343-11008 is available.

Perhaps there is no reason. Or perhaps the ROQ playback works in pretty weird way (and FFmpeg videos try to repeat them as perfectly as possible). And the people who made the original briefing video had some issue which disappeared with "loop" keyword. Recall the in the original system, duration of the video was specified manually in GUI file. If it was a bit longer, then the video might... play from the beginning? Don't know. Anyway, there is no reason to set "loop" in the modern videos.

Yes, I noticed it too, it's pretty annoying. These days TDM uses OpenAL, and it selects device on sound system start. I guess OpenAL is too low-level, so it sticks to a specific device and does not care about OS changes. Pretty sure it is fixable, perhaps with some OpenAL-Soft extensions. Just need someone to investigate it. It should not be too hard or too mixed up with other stuff...

And by the way, if you still hope to "max the game". Open game console, type "r_fboResolution 3" and hit enter. Congratulations! Now you need 9x more performance to maintain the same FPS. There is always some way to waste your GPU, be it 1050 or 4090. And TDM is not a big single-release commercial game which can test everything on many PC configurations and only provide "safe" options to the players.

I wonder why the discussion lasts so long Yes, indeed there are several graphical settings which require tons of performance but don't work well enough. I think we are aware of it, but it won't change overnight unfortunately. If you have performance problems, use stencil shadows, avoid making them too soft, avoid too much antialiasing... Is it all, or did I forget anything? In general, tooltips in the settings tend to note which settings are overly taxing for performance. Comparing antialiasing to modern games is totally unfair, because modern games stopped using multisampling almost completely. They just use TAA without increasing memory bandwidth that much, of course it is faster. I'm not even talking about all that upscale/framegen.

"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: dev17376-11017 * Added new character model: atdm:ai_undressed_old_man_01. Includes LODs, ragdoll, swappable head. * Fixed some potential memory issues, more cautious floating point compiler settings. * Don't allow func_fracture to spawn decals too fast (6588). * Changed starting frame of the walk1.md5anim so it blends better with idle animations (post). * Updated walk.md5anim animation to fix incorrect arm rotation (post). () * Builder guard will now use walk.md5anim animation. * Replaced animations idle_turn_90_lft.md5anim and idle_turn_90_rgt.anim (post). * Disabled "shifting" idle animations during walking (post). * Proper sounds will be played on certain frames where idle animations replacement were used. * Brought back specularmap in "builder_armor" material. * Fixed specularmap on blocks_light_stained_trimmed. * In training mission, removed errant clip brush and fixed hidden gas arrows. dev17343-11008 * AI should now notice absence and blood markers again (6623). * Most visual stims are now more frequent, at least 2 times per second (6546). * Fixed performance issue of infinite decals on brittle fracture (6588). * Hopefully, dmap no longer leaves out-of-date files around (thread). * Fixed parallax confusion on wood/panels/trim_wood_grunge_moulding_desat. * Fixed shop description of slow match (6629). * Added red variants of trim_wood and panel_decorative materials. * Added new paint_paper materials (fleur, gold). * Added old_bricks_darkgrey_wet, red_worn_dirty_trim_wet, painting_downlight.ase. 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. 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. Known problems: * Compass breaks player HUD (thread).

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.