stgatilov

I investigated the topic, and I still think it is too hard. Precomputed visibility is perhaps the best thing for us. So we can split space into cells, and precompute whether cell A and cell B have unoccluded straight line connecting them. We can limit occlusion only by brushes: there is no need to take models/patches into account. Precomputed visibility should be done on per-area basis. When we compute the visibility data for one area, we consider all visportals and all other areas opaque. In other words, we only check for direct visibility within the area. If such information is available, it can be combined with existing visportal&area traversal code. The main problem is how to precompute visibility on per-cell basis. A solution must: Be conservative: you don't want to occasionally see small holes into nowhere Do perfect occluder fusion: otherwise a big house would not occlude most of the stuff behind it. Have sane build times for brush geometry of our scale. This inevitably leads to pretty complex algorithms. If mapper can add a special brush and say "this is major occluder in visarea N", then we can probably (not sure yet) verify that he is correct in saying that, and simply raytrace this occluder during visportal traversal. But realistically... I don't think mappers would really use this tecnhique, except maybe for a very few people/missions.

The problem I have with antiportals is that using them is too hard. If the obstacle is small, then antiportal won't help much. If it is huge, then it's probably some building and you try to optimize outdoors area. The antiportal over whole building makes sense, but: Rectangular antiportal is not enough: you need something that fills as much of the building's volume as possible, at least a box or two crossing antiportals. Are you really 100% sure player cannot open doors and look through the whole building? Are you sure you would set antiportal in such a way that it won't block something visible? Your antiportals cannot affect all areas like visportals do, because when player is indoors, the antiportal will block his visibility. You want antiportal to work only when player is outdoors, so you need some filter with locations. It becomes so messy that if a mapper wants to optimize his building, he just better place all the portals around and hope for the best.

Occlusion culling is not as easy as it looks. For instance, if you simply check entity's bbox against individual brushes, then most of the entities behind walls would pass the check because no individual brush covers a whole entity completely. Also, there are dozens thousand brushes on large maps, you cannot iterate through them naively. On the other hand, this is close to the concept of "antiportals". That's when mapper puts an "antiportal", ensuring that everything behind it is occluded, and the engine takes it into account whenever it works with portals. But this requires work from mapper, and I don't think it would provide much help. To get serious benefits, you need to recognize the whole wall consisting of many brushes as a single inpenetrable surface, at which point you necessarily have something really complicated. I thought about doing Umbra-like occlusion culling on brushes (with automatic portals and conservative rasterization inside), but I realized it's ton of work. There is always something else to do. By the way, the recent change is not about what player does not see, it's about what light don't see/hit. Just rendering a surface is very cheap because of depth prepass, but light interactions are costly with all the textures, soft shadows, etc. Realizing that you don't need light interaction on something you see is quite beneficial. The problem with original Doom 3 engine is that it basically lights up all objects within light volume. With the exception of static shadow-casting lights, portals are just ignored! I have expanded usage of portals to dynamic lights. It might sound funny, but there is still some room for improvement in this area...

dev16809-10394 is released. This version might give a noticeable performance boost depending on a mission. Let's hope it does not bring along more bugs

Did you find anything?

Maybe you can check if you can reproduce it without Frontend Acceleration. And if you can, then try also com_smp 0.

As a matter of face, I cannot reproduce the issue on High Expectations as well.

How do you cancel shot? Does the same issue happens to you on other maps?

"player1_weapon" entity usually has two attachments: so-called aimer, and arrow. In this crashdump, the aimer is here, but arrow attachment is dead: it was deleted beforehand, without clearing the attachment reference. And since this code does not check e for NULL, it calls a method on NULL object, which certainly crashes. I'll of course add a check for NULL here, but it would be interesting to understand what kills arrow attachment, and why this problem does not happen every time. UPDATE: Since everyone reported the arrow to be missing just before the crash, I suppose the real issue is that arrow entity is occasionally lost...

It can be easier to trigger on Debug build. Also, the ability to record crashdumps might depend on some Windows OS settings. You can first try to execute "crash" console command and see if you can record a crashdump from it. Just to be sure everything is prepared properly.

Yes. I think it would be even easier if you take clean 2.11 installation and record crashdump on it. This way our release PDB would match your crashdump automatically.

Here you can select configuration. The default one is "Debug" for some reason. It is interesting, because we almost never use pure Debug these days The problem is that "Debug", "Debug Editable", "Debug Fast" all use FASTLINK setting for debug information, which makes PDB file useless. Only "Release" configuration can generate crashdumps that can be passed to someone else for analysis (with PDB file of course). It looks like I can see some stack traces, and the main thread seems to "wait for frontend". It would be interesting to see what is wrong with e->spawnArgs value, but my debugger does not show anything.

Well, this is not a release build, so it is unlikely I can use my PDB. Which build it is, at least? It is near executable. It has .pdb extension.

I suppose you built your own executable. So crashdumps generated on it can only be opened with PDB file that was generated alongside it. It is possible to hack PDB file to "match" EXE file (works fine if you were using Release build of 2.11), but unfortunately it does not work for a crashdump, and I don't have your executable that crashdump was generated for. So either attach a PDB or at least EXE. If you rebuilt TDM executable after recording crashdump, then I guess crashdump is no longer openable.

The crash inside idDict access might be race condition. idDict use global string pool without mutex, so two threads cannot access it simultaneously. But the culprit is on the main thread then: frontend thread runs gameplay code which can legally access idDict-s. I will download the dump and see myself what's going on. Maybe we should add assert for threadID inside idDict/idStrPool? Maybe even leave the check enabled in release, so that if such a problem happens, it leads to Error/crash in 100% cases...

It's probably nothing more that goes wrong, and reading wrong memory by itself does not crash often (it is usually valid memory page, and depending on the build its contents can be quite deterministic). It is not the first time where such issues cause crashes on Linux while Windows build seems to work fine. Also, we might have different compile settings: Linux build settings are pretty standard, while Windows ones have e.g. security buffer checks disabled. Even calling conventions are very different between Windows and Linux. Most of C++ worshippers don't look any further than "we get undefined behavior here"

My guess would be: the door generates visual stims that AI can notice the stim has "AIUse" spawnarg which specifies its type, which is 7 = "AIUSE_DOOR" the AI code casts the stim source entity to CFrobDoor, which it is not -> crash Here is the place with non-checking cast: else if (aiUseType == EAIuse_Door) { // grayman #2866 - in the interest of reducing stim processing for closed doors, // add a check here to see if the door is closed. Otherwise, a closed door will // ping every AI w/in its radius (500) but the AI won't shut it down until it // can see the door. A guard not patrolling will receive endless pings unless // we shut it down here. CFrobDoor* door = static_cast<CFrobDoor*>(stimSource); if ( !door->IsOpen() ) { door->DisableStim(ST_VISUAL); // it shouldn't be pinging anyone until it's opened return; } Supposedly, you changed the entity C++ class from door to static entity, but did not remove the "AIUse" spawnarg. Maybe we should add IsType check here and do Error if it is incorrect.

@nbohr1more can provide you debug symbols from the assets SVN repo (for 2.11 release only, not for dev builds). They are zipped inside devel/release directory. I don't have my main PC available right now, can't do it. Then you can run "gdb ./thedarkmod.x64", within gdb execute "add-symbol-file ./thedarkmod.x64.debug", and run the program to reproduce your issue.

1.5 seconds after start is probably the time when script functions are called. Or some other post-spawn activity. Someone can also share LInux debug symbols for 2.11 release (they should be in assets repo somewhere inside devel). This way we can probably see stacktrace. Also keep in mind that the threadname message might be not the error itself, but some issue happening when game tries to throw exception or stop something after the issue has already happened.

This problem most likely happens in all the missions with custom briefing released before 2.10. I don't want to waste so much time and nerves on such a minor issue.

dev16801-10370 is available.

And the same problem applies to every button in the mission start sequence which is more specific than "back": "Objectives" button on default briefing "Start mission" / "Buy Equipment" button on difficulty selection screen "Difficulty" button on shop screen Instead of trying to reproduce the state-switching logic of C++ code, better rename these buttons to something generic like "Next".

That's because this mission overrides mainmenu_briefing.gui and it does exactly that: /*************************************************************************** * * The "Back" Button * **************************************************************************/ windowDef BriefingNewGameButton { rect POS_BRIEFING_MAIN_MENU_BUTTON matcolor 1, 1, 1, 1 background "guis/assets/mainmenu/buttons_start/back" visible 1 } windowDef BriefingNewGameButtonH onAction { set "cmd" "play sound/meta/menu/mnu_select;"; // Switch to the mod menu set "gui::targetmode" MM_STATE_MOD_SELECT; resetTime "MainMenuModeSelect" 0; } } This file was written before The Great Main Menu Refactoring, so it uses explicit state names. The correct modern approach would be to set "gui::targetmode" MM_STATE_BACKWARD, which would cause engine to look what is considered previous in builtin tables, and hopefully move to main menu. Also, this file was written before the change related to start mission / install mission. At that moment, current mission was started from mission selection screen, so this custom gui redirects to that screen instead of just main menu.

I guess footstep sounds are played from within source code. So their volume can only be changed there without information loss. There are already many cvars about that, but a brief glance shows that perhaps they are ignored...