stgatilov

dev16818-10434 is available. As for renaming Stealth Score, I see lengthy discussion but no resolution yet...

Frob outline is dead since 2.11. People can still use it because the code for frob outline has not caused much trouble yet. The frob stages are still used. The main difference is that now they are automatically generated for all materials, and tweaking them takes less text in most cases.

I committed your patch. Not sure this is about standards BTW.

Yes, these states were added during the big main menu refactoring. At that point I supported skipping states because of well-known "how to skip GUI briefing after video?" issue (also Grayman asked to skip something like success screen). Of course, dozens of old missions still target explicit state. They do work as intended. If you want to modify them to skip something, better fix their GUI to new conventions first.

Perhaps you look at missions which explicitly specify MM_STATE_OBJECTIVES as the state to switch to in their customized GUI code. You cannot simultaneously disable a screen and switch to it As a rule of thumb, only MM_STATE_FORWARD and MM_STATE_BACKWARD should be used to switch screens. This approach should play nicely with disabling states.

I think there is a define for difficulty selection screen in custom_defs which can disable the difficulty selection. But to be honest, I don't know what would happen with difficulty-dependent things in this case...

Perhaps you did some OS/driver update? The only other thread with same error is: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8350 And it is some kind of shadere compiler bug that has been fixed. Maybe you can update or downgrade something in mesa...

A known appraoch is to do screen-space raytracing from rendered fragments as additional check. But it is quite costly this would return some shadow boundaries to hard shadows... and also I'm sure it will bring even more artefacts as screen-space technique.

Yes, exactly. There is single code piece which handles "fromVideo", and it accepts material name, as FFmpeg video wiki says. And the virtual sound sample is named like "fromVideo {mymaterialname}", by this name you assign subtitles to it. Yes, but you need to change the SUBTITLE_NAMEPREFIX to something unique, or you'll get a ton of warnings about name collisions. I think standard debriefing video should not be skipped. As for debriefing, we don't have anything like that yet in core.

I'm pretty sure I tested this case. Note that subtitles display only if there is appropriate GUI. If you have your own overlay or own GUI file, then you might be missing proper #include of subtitles.

Simple reason to avoid local shadowing parallel light of any kind: And this is fully within one area. When walls, areas and portals appear, things get worse.

Actually, "parallelSky" spawnarg implies "parallel" in the engine. You don't need to set both flags, just make sure to set "parallelSky". For a noshadows light, they both behave exactly the same and have no issue. In terms of spawnargs, "parallel" spawnarg without "parallelSky" spawnarg should be deprecated. I think this is what I can check in dmap and give a warning. Maybe I'll exclude noshadows "parallel" case because it is equivalent anyway. In terms of functionality, there is nothing being deprecated: parallelSky serves as better replacement or is the same in every case. Yes, local shadowing parallel lights never worked, still don't work, and I'm afraid will never work. If someone wants to use them, he can slap "parallelSky", but I'd seriously advice against the very idea.

The idea is to deprecate Doom 3 style "parallel" light. Use "parallelSky" light instead. And if you want the light to have shadows, then: make it global, i.e. cover the whole world make sure portalsky material marks the sky instead of caulk or anything else hope that it works

I think there is no problem with noshadows parallel lights: they are well-defined in the current engine. It can be used as local light to brighten the window, as @HMart does. I hope there is no reason to have shadows in this case? The parallel and parallelSky are almost the same thing, except that parallelSky traces light beams from areas containing portalsky world surfaces, while parallel traces light beams from the area where light origin is located, which is never what you need for a global parallel light (like moonlight). There are many missions where this issue is hacked around, and all of them result in issues like double lighting if door is open, or lack of lighting in some outdoors areas. And there is no way to fix the engine to make these missions work properly --- the maps themselves are wrong. If you want to do a global parallel light, the parallelSky is surely what you want to have, and parallel is most likely not. But note that to make parallelSky work you also need to follow some rules. The issue with local parallel light is that objects outside light volume can cast shadow over objects inside light volume. This is pretty weird by itself: you move object closer to light volume, and at some point its shadow instantly turns on. The engine determines whether object intersects light volume approximately (using bounding boxes and such stuff), so whether you get shadow from an object close to light volume or not is implementation-defined. Today you have no shadow and it looks nice, tomorrow culling is changed and the scene gets unexpected shadow. So the bottom line is: Global parallel lights should use parallelSky and follow some rules. Local parallel lights should be noshadows. All the rest is not well-defined: you'll avoid a lot of trouble by avoiding it altogether.

I think we should deprecate parallel lights. The way they are implemented in Doom 3 only works intuitively if it is fully contained in a single visportal area, which is rarely the case. Otherwise, there are huge issue with area-portal graph and shadows. For something global like moonlight, the new parallelSky light should be used. If it is contains the whole level in its light volume, then the behavior should be well-defined as long as portalsky material is used to seal levels from the sky (not caulk or something similar). The light is supposed to come through the portalsky surfaces into all areas in this case. Are there any other usages of parallel lights?

Maybe this: https://bugs.thedarkmod.com/view.php?id=6244 ? If yes, please leave a comment there about how much it breaks existing mission. Such circumstances greatly raise significance of an issue, at least in my eyes

Well, the previous dev build introduced a bug with noshadows lights. Their lighting can be optimized away in some cases, for faster performance and wrong results The upcoming fix will probably reduce performance a bit back, although it seems to be rather small.

Every light volume is represented as a frustum. Indeed, spotlight has smaller frustum than ordinary point light which is shadowed, so it generates less interactions. It should be faster in most cases. Currently shadow maps always use cubemap, even for spotlights. But I hope we'll change that too in the future.

dev16814-10408 is released. It finished the optimization on shadow-casting lights, might give some more performance.

Another issue is that sound mixing sometimes changes. The lockpicking section in the training missions includes a case when player needs to pick a lock with a noisy machine nearby. I remember when I played it first time, the generator noise made lockpicking sounds totally inaudible. But since then, sound mixing has moved to OpenAL and maybe something else changed, and now this section looks stupid. Because I can pick lock as usual, the generator does not block lockpicking sounds for me. Perhaps this can be implemented. Of course, it would require more sound propagation processing: now we only trace sound from everything to player, and from player (maybe something else?) to AIs. With this proposal sound has to be traced from everything to all AIs. The masking computation can be done based on overall amplitude or sound sample + final volume. It is not correct but should probably be find as long if we stay on conservative side. On the other hand, it is hardly possible to deal with multiple footsteps issue. There is too much cues that human brain uses here. For instance, it is a thief with special boots would have footsteps very different from footsteps of guards, especially if guards carry armor. Also, a guard might know were his buddies can/should walk and where they should not, and can get suspicious depending on that. Also, thief probably has a very different tempo of footsteps: he moves in more irregular fashion, and never talks while doing so.

In case of stencil shadows, there are two parts: computing shadow volume (on CPU) rendering shadow volume (on GPU) Shadow volume computation is cached in interactions table for each light+entity pair. It is recomputed only when at least one of them changes. Rendering shadow volume cannot be cached because it depends on camera too much. So with stencil shadows it is already good. Yeah, it is possible to skip shadow volumes computation for distant lights. In case of shadow maps, there is also some CPU filtering and actual rendering on GPU. CPU filtering is also cached and only recomputed on light or entity change, but on GPU shadow maps are rendered from scratch every frame. And this is not good: at the very least, static light which has static set of shadow casters should not have its shadow map recomputed every frame. Perhaps it is also good to have shadow map of static entities saved persistently, then every frame copy it and render only dynamic entities on top. I have this issue in my mind for some time already. There are some issues here, since shadow maps which are not recomputed must not change their location in shadow map atlas, and thus they can block other shadow maps from taking proper space (basically, typical memory allocation issues). Also if we try caching only static portion of shadow map, then we have to create another shadow atlas for them, which raises memory requirements dramatically. Right now it is not possible to skip anything for shadow maps at all. It might become possible after I implement reusing shadow maps in static cases. Overall, I can't say I like this idea. Even if light is distant, it is still ugly when shadow does not move in sync with shadow caster. But shadow maps should definitely be optimized for static cases.

FXAA is cheap but looks awful. Supersampling AA is strictly more expensive than multisampling, no reason to use it if multisampling looks OK. Temporal AA requires major changes in the engine in order to be used, plus it kinda requires motion blur to hide its uselessness on fast camera motions. So don't expect multisampling to be replaced soon.

In order to better discuss performance, please look into this article: https://wiki.thedarkmod.com/index.php?title=Tracy:_timeline_profiler#Gameplay Perhaps inspect some Tracy records too. The game consists of four main parts, most of them run in parallel: game modelling renderer frontend renderer backend GPU Let's suppose n-th part consumes Tn milliseconds of time on some interval, then the interval takes min(t1 + t2, t3, t4) of time in total. Usually either p.1 + p.2 or p.4 are bottleneck. If you try doing less updates, you cannot make renderer backend and GPU faster: it still has to render all the stuff every frames. Except for something like reusing shadow maps between frames, which is not implemented yet. You can make game modelling faster if some entities skip thinking. The most time-consuming entities are AIs, and this kind of optimization is applied to them since the very beginning of TDM, known as "interleaded thinking optimization" (Doom 3 had similar but stronger "dormancy" concept). If an AI is behind closed doors and far from player, then he thinks rarely, e.g. 3 times per second. You can use cv_ai_opt_forceopt cvar to experiment with it. It took much effort to make this work reliably, but without it TDM should be very slow on anything but small levels. And this optimization caused some headache later, for instance it caused distant AIs to randomly die with uncapped and low FPS. All the other entities think every frame, as far as I know. Some entities are known to be dangerous to think rarely: that's mostly physics-related things like ropes and ragdolls. Another thing is that many entities spend negligible time in their Think methods, and most entities don't think at all (only "active" entities think, see listActiveEntities command). Speaking of renderer frontend, you can update entities less often. Then you can reduce time on understanding which areas entities belong to, and on generating interactions (that's the main part I think). However, there are parts of frontend which are view-dependent, so they need to run every frame. You can experiment with cvar r_skipUpdates. As far as I understand, it disables all updates of render entities/lights from game code. The game modelling still runs, guards still move around, see you, speak, chase you, and kill you. But renderer displays the obsolete state of the world from the moment when you set the cvar.

I guess the difference is because of long-standing issue was with stencil shadows: https://bugs.thedarkmod.com/view.php?id=5851 Other then that, multisampling is a big waste of memory bandwidth, so antialiasing will never become totally free in TDM.

I can reply with the very same text: why fixing tiny issues of developer/cheat commands in any version if they get broken anyway a year later? We usually support and fix some commands/cvars that mappers use regularly when working on missions, but that's it. I don't have that much time fixing all the minor stuff. It does not pay off fixing some noclip issue that you can a) not get into, b) fix with other console command. When game developers follow the idea "all console commands must work flawlessly", they usually close the console, so that players cannot get into it And yes, that's how testing works: the software is tested constantly, again and again, and the very same bugs are discovered again and again. There was definitely a case when we aimed for stability release (like 2.07), but I don't feel 2.11 is anything close to that.