stgatilov

I don't think this log will explain anything. If you experienced a crash during gameplay, you can explain where and how it happened, is it repeatable, post a savegame, share a crashdump. Speaking of crashdump, you can run TDM under gdb and execute generate-core-file gdb command after it crashes.

Actually, that's the main reason why all software gets slower over time.

By the way, revisions 9966 + 9967 broke test/glass map pretty bad. It has a glass wall near starting location, which consists of 8 glass windows of different material. Previously, it looked nice from all directions. But now when you look them from behind, they toggle on and off as you walk around.

Yes, that's exactly what I'm talking about regarding BSP tree. World brush geometry can be put into its own BSP tree by dmap, which can be rendered in perfect back-to-front order. UPDATE: But, even static geometry will cause problem with postprocessing surfaces. Because you have to copy renderbuffer befor every postprocessing surface rendered in order to get proper picture, and that's very expensive. With depth peeling, you need to copy renderbuffer after every layer, if there is a chance that next layer will include postprocessing shader.

If you suggest something like depth buffer, then you'll eventually get at the technique called "depth peeling". It works by rendering all translucent surfaces over and over again, rendering exactly one layer of translucent surfaces one every phase, until all layers are rendered and nothing changes. This is quite expensive, although the true cost depends on maximum degree of overlapping. If you suggest something like sorting surfaces from back to front on CPU, then you get a well-known unsolvable problem. The worst thing here is that when surfaces' boxes intersect, their order toggles back and forth as you run around them. In order to perfectly solve depth sorting in general case, you have to split surfaces. For static geometry, BSP tree is the best way to do it: that's how e.g. Doom worked without depth buffer. But adding dynamic surfaces into BSP tree is still an issue.

If they have same material and "sort" value, then they are eventually sorted by surface index. This order is constant in one playthrough, but can change even if you restart the game. And if you have two postprocessing surfaces on the same place, then both of them will be visible if they render in correct order. If the closest surface renders first, then the farthest surface won't be visible.

dev16519-9985 is now public.

I removed DSF_SORT_DEPTH flag and new sorting code. I committed test map to assets SVN as test/5990_render.map. I did a few adjustments to the map, most importantly set "drawSortOffset" "1" on the window: now it renders properly always. However, this assumes that player cannot get into water: it player is inside water, then he won't see glass windows behind water obviously. Speaking of "drawSortOffset", I think it has some issues right now: 1) I have a pool of water, and I know player cannot get into this pool since the level is too low. I'd like to make sure this piece of water renders before all the surfaces with similar material. I set "drawSortOffset" "-1" on the water, and its rendering is totally broken because it is no longer considered "postprocessing", thus framebuffer is not saved. Setting "drawSortOffset" on the window is possible but hardly a good idea: I don't have any guarantees about window, so I should not have to tweak it. 2) drawSortOffset is an integer, so it is not very applicable to ordinary translucents. In fact, the original D3 way of tweaking translucents is by classifying them into "close", "medium", "far", but that's only possible in material. softOffset works well only for afterFog, postProcess, last classes, since their "sort" values are far from each other. But: mapper must know that he cannot set large values, or he'll break everything. Wouldn't it be better if we: Sort by "sort" class first, then by mapper's "drawSortOffset", lastly by surface index. In other words, let softOffset be tie-breaker, instead of a way to break classes in implementation-defined way. Allow mappers to override "sort" class of entity by spawnarg. So if mapper decides that some object is not really "close" but should be "medium", he sets "drawSort" "medium" spawnarg on entity and this is used instead of the value from material. I'm not even sure it p.2 is necessary. Ideally, these close/medium/far classes either should not exist, or should be totally certain so that mappers don't need to override then on per-entity basis.

v141_xp is VS2017 with Windows XP support. You need to run Visual Studio installer and find "Windows XP support" there somewhere, enable it and allow installer to download more stuff to your computer. Then it should build fine. Alternatively, you can change v141_xp to simple v141. If "retarget solution" does not help, then you can close Visual Studio, then find all .vcxproj files (at least two are important), open them in text editor, then search and replace "v141_xp" with "v141" everywhere. Or you can go through all projects manually in Visual Studio, look at their properties, and in General section change Platform Toolset to "Visual Studio 2017 (v141)". Be sure to switch to All Configurations and All Platforms before doing so.

Well, mapper can at least establish relative order between translucent entities of same-kind material. But I think it is not possible to do this in script right now. Yes, it is not perfect, but it should work. It would allow "user-assisted translucency" for those who dare. I don't think there is anything like that. Moreover, SEED is hardly a good piece of code to look for admiration...

@duzenko, how can mappers control render order now, including dynamically from script? Can they set "sort" parameter directly as spawnarg? Can they set something like "renderOrderOffset", which only affects order of surfaces with same "sort" value? Can it be done in script during runtime?

On VirusTotal only one piece of software reports something, and that's not Avira: https://www.virustotal.com/gui/file/3eb8c46eeeb508454457bf392a16bb5ff83e244bfa5cb333cb93a02d3e14e0c3

Then let's remove this sort by some matrix element, and think how to allow mappers tweak order dynamically in such a way that we won't break it in future.

BTW, there is another solution straight from the days of the first Doom: we can use BSP to establish rendering order. But: Our BSP is too large to traverse in realtime, so we should build a separate BSP only for translucent geometry. If some surface is split into chunks by BSP planes, we must not merge it back: we must retain each chunk as separate surface and order + render each chunk separately. Obviously, this only works for world brushes: no entities, no patches, no models. It is not obvious how to merge unsupported translucent geometry into BSP order... maybe by some origin point. This requires quite serious effort on dmap + rendered frontend + integration with backend.

I think the best solution would be to save the current way of rendering objects, but allow mappers to specify tie-breakers in scripts. Don't try to make clever automatic solution, it won't work and won't be easily configurable. If mapper really wants to get complicated translucency work, he can often get away with some simple conditions like: if in area Q, then render A then B, otherwise render B then A if coord X < 1540, then render A then B, otherwise render B then A But for this to make sense, we need to guarantee that we won't try to tweak anything above this tie-breaker ourselves. We won't change "sort" variable in core materials, won't split its values into more classes, etc. All that tweaking that you did in the core game must be stopped, because if you continue, you'll break mapper's translucency tweaks.

After some more consideration, it won't work, even in limited case. Actually, nothing will help. You'll just replace one problem with another, no matter what you do. Translucency is common problem which remains unsolved. If you have ordinary translucent objects with common material, then you can at least do some OIT (like per-pixel lists, depth peeling, or weighted approximation), but if you need to copy background, nothing of it works. Just remember that you should not have more than one heatHaze material per view, and that if you have many translucent objects, they'll probably render in wrong order.

In order to depth sort, it is desirable to take bounding box of surface into account. That would allow to support world surfaces, and entities not centered at origin. Depth sorting has one major problem: as player moves, objects order sometimes changes, which results in a hugely visible "toggling". In a sense, it is more pleasant to render surfaces in fixed order than to sort them dynamically. Wouldn't it make sense if we apply proper sorting only for static surfaces whose bounding boxes don't intersect? I believe it is possible to reliably decide which box should be more distance in this case. Not sure yet what to do if boxes intersect, or how to mix it with dynamic objects: comparison must be transitive...

So if you have two similar translucent objects with different colors, they will look good from one side, but wrong from the other?

So, the latest commits are trying to add "sort by distance/depth" for some surfaces, as well as allow several copies of currently rendered framebuffer. I wonder: how is the problem of Z sorting solved for translucent objects? I mean: the engine probably already has some sorting for translucent objects to make translucency correct... where is it implemented in the code?

Actually, I'm still not certain the script does anything with T-pose issue. I spent a week trying to understand and replicate it to not avail. It is probably some timing-sensitive bug which just just does not happen with script... thank god it does not The original release has 180 "neverDormant" spawnargs but the map has almost 300 AIs. I guess that's why the script improves performance even further.

As you probably remember, I'm strongly against tying LOD setting to all kind of unrelated graphics settings I did not look the latest commits yet, but I think I glimpsed this kind of dependency...

Returned to this story. Looking at flathub requirements: It means running tdm_installer is explicitly forbidden.

To whoever has access to SVN and Visual Studio. I have applied the original patch by @Daft Mugi, except for the code in Physics_Player for automatic crouch/uncrouch depending on direction. And I did not add a cvar, since I believe this change should simply "be or not be" I'd say it feels good. Some minor questions: Pressing crouch on ladder results in crouch indicator quickly going down/up. Perhaps it would be better for it to stay "uncrouched" until sliding down starts? When slide-down is over, player stands up on key release, regardless of whether he was crouched or not when he initiated the slide. Initially I through it would be wrong, but on the second thought this is better because player can simply remember that he will be standing after slide-down, and crouch on muscle memory if he wants.

@Daft Mugi, then don't waste your energy right now. Just wait a bit until some more commits come, then say what's wrong. Such discussions are lengthy, especially when no perfect solution exists. I think sooner or later we come to same solution as @Daft Mugi . I'll review the original patch and see if I can remove the direction-specific behavior but retain the ladder/rope + slide-down handling.

I'm asking the people who had the original problem, i.e. guys on rather vanilla Windows 7. Like @Gadavre