MirceaKitsune

OMG... can't wait to try this one out! It's a shame I don't know the engine code and C++ in general: I always think of optimizations but all I can do is share them hoping it may inspire a developer for their idea. stgatilov did some amazing work I wasn't expecting we could see, thank you for that it's awesome

The new update sounds very exciting! Already got it and will probably play a new FM again soon. I wasn't sure if lights make full use of portals in order to ditch even more calculations, awesome to hear that's now on the list too Reminds me of something I asked a while ago, don't think anyone knew the answer with certainty: When using a targeted light / spotlight, does it improve performance compared to omni lights? I wasn't sure if the engine knows to calculate only inside the cone they're pointing at, or if behind the curtains it still treats them as 360* projections and just visually makes them a cone. If there's an improvement I was wondering if hooded lights could be made like that by default. Visually there should be no difference: I experimented with the outdoor lamp once, by default it still shines in all directions... you don't see anything above anyway since the model self-shadows, we could likely get it looking almost identical with a wide cone. Just thought it might be a good idea to bring this up now that I remembered, for now a nice new optimization to enjoy

Cheers. Initially I was thinking of this for lights... later thought to include animated models too, mesh deformation isn't that expensive so I can see why there's little benefit. Especially as I realized per-pixel lighting would still be recalculated each frame, specularity also depends on camera angle not just model movement... technically we could frameskip that too but I'm getting way ahead of myself for what would likely be a tiny benefit Could this still work for lights though? Recalculating shadows when something moves in radius of a light is a big cost, even if it's gotten much better with the latest changes. A shadow recalculation LOD may give a nice boost. We could test the benefit with an even simpler change: A setting to cap all shadow updates to a fixed FPS. This would probably be a few lines of code so if you can give me a pointer I may be able to modify my local engine clone to try it. If it offers a benefit it can be made distance-based later. Another way would be to make a light's number of samples slowly decrease with distance, the furthest lights dropping to just one sample like sharp / stencil shadows: Shadow samples also have a big impact. What do you think of this solution as a form of light LOD, maybe mixed with just a shadow update LOD? These actually sound like they make sense; If you think it's worth it I can post those two on the tracker so they're not forgotten.

I'm seeing the improvement with shadow maps too, albeit I keep their quality at lowest. Indeed MSAA is still costly even so, I kept it disabled even now for that reason. Fingers crossed the next release may get shader-based Anti-Aliasing: From my tests in Tesseract / Redeclipse, FXAA / SSAA / TAA all tend to be cheaper, hope we get at least one someday.

If this is referring to loud noises covering the AI's hearing, I agree that should be a thing. Imagine a guard standing in a room where a loud generator that blows the player's headphones off is running: It makes no sense that in such noise the guard will hear the player's footsteps and be alerted to them, they can't hear anything in that noise! It sounds like a good idea to at least give speaker entities a coverage spawnarg, though this one should be done universally if you ask me: The volume of every sound heard by an AI should decrease its ability to hear other sounds and become alert to them, at maximum loudness the AI can't be alerted by other noises any more.

A few additions and observations: We may get even better results using not just distance but also the entity's size, given the rate should probably depend on how much the entity is covering your view at that moment. As this shouldn't need much accuracy we can just throw in the average bounding-box size as an offset to distance to estimate the entity's total screen space. A small candle can decrease its update rate even closer to the camera, while a larger torch will retain a slightly higher rate for longer. To prevent noticeable sudden changes, the way LOD models can be seen snapping between states in their case, the effect can be applied gradually without artificial steps given it's just a number and may take any value. It might be best to have a multiplier acting on top of the player's maximum or average FPS: If your top is 60 FPS, the lowest update rate beyond the maximum distance would be 30 FPS for a 0.5 minimum setting... along the way one entity may be 0.9 meaning it ticks at 54 FPS, a further one 0.75 meaning 45 FPS, etc. Internally there should probably be different settings for model animations and lights: A low FPS may be obvious on AI or moving objects so you probably don't want to go lower than half the max (eg: 30 FPS for 60 Hz)... for lights the effect can be more aggressive on soft shadows without noticeable ugliness (eg: 15 FPS for 60 Hz). In the menu this can probably be tied to the existing LOD option which can control both model and frameskip LOD's.

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

I have an 144 Hz monitor for a couple of years. My main wish is for TDM to never go bellow 120 FPS, which still happens on low settings but is still pretty good compared to the past. I use VSync as I don't see any benefit in stressing the video card for more frames than the monitor can render, problem is it's still hard to reach the monitor refresh limit constantly. Regarding other bottlenecks like input lag or perceived performance, it would help a lot if the engine had native Wayland support on Linux rather than still going through X11, still yet to happen to my knowledge. I use the stock amdgpu driver and performance is pretty amazing all in all, latest dev snapshot did wonders and it will prolly get even better

Thanks for clarifying. Unfortunately there's still a bug as the barrier never goes away: When I first enter the apartment the husband says "is she hurt, please put her on the bed"... I do so and the objective is completed, but after that the husband says nothing else and the barrier never goes away. I looked around the room and tried frobbing him, but nothing ever happens for some odd reason. Wonder if some triggers or signals got broken in latest dev?

For some reason I thought this FM was just released, didn't realize it's 3 years old already! Just finished it at last with 5100 loot and 3 secrets found, not bad for something of this scale. I was stuck on one of the objectives but finally found it so I removed my question. This has to be the most structurally intense FM ever made: I don't think a city of quite this size and complexity was ever done for TDM in one map before, the parkour and little hidden areas are insane! This is nice albeit mentally straining as it's impossible not to miss something or properly keep track; In many cases I had to noclip to discover how to get to certain areas, reloaded and went there without cheats afterward but don't know how I could have found some areas otherwise. Easy to get lost but this is compensated by the extremely useful feature of the map highlighting where you are so you don't have to guess using signs. Ran into a few bugs. Most noteworthy is a breaking glitch that makes it impossible to continue without noclip: Other than that nothing too significant: Managed to catch a case of a door that opens too wide and goes through the railing, there was a hatch that did it too but I forgot that one. I can also confirm the black box bug... first thought it's caused by my mod to remove spiders because I have arachnophobia, they set the entity to null however so it shouldn't be a box per say.

Noticed something rather shocking: Enabling 4x MSAA only seems to reduce performance by roughly 10 FPS now. This is a huge optimization, AntiAliasing would tank performance to a far greater extent! I'm seeing it on The Painter's Wife where performance is generally good, if it holds in other places I may be able to leave it enabled at last; Still wish we had an alternative like FXAA or TAA but now it may not be so urgent at least.

As I don't know what else to do to help debug this, I went through the process of verifying if the issue can be reproduced in a VM. Took me over an hour due to some problems on my end, in the end I managed to confirm that it can! I've laid out the exact steps needed for anyone (including Windows users) to reproduce this: Install VirtualBox, get the Manjaro KDE / Plasma iso from https://manjaro.org/download In VBox create a new VM of Type: Linux, Version: Other Linux (64-bit). Under its Settings - Storage add the iso as optical drive with the option "Live CD/DVD", also add a virtual hard drive to install to. Booting up the VM should start a live Manjaro session. It will provide a prompt to start the installer; Do so using the default settings, choose any username and password but don't enable automatic login. Restart once it's finished and boot from the virtual drive instead of the iso (F12), the VM should now load into the installation. The SDDM login manager should present you with the login screen after booting. Before typing your password look in the bottom-left corner: You have options for Plasma X11 and Plasma Wayland, click it and select the later. After changing the session type use the password you chose in the installer and log in. Open a console (Konsole). Clone DarkRadiant with "git clone https://github.com/codereader/DarkRadiant.git". After that follow the instructions at https://wiki.thedarkmod.com/index.php?title=DarkRadiant_-_Compiling_in_Linux to install Manjaro dependencies with the "pacman" command followed by "cmake .;make --jobs=4;sudo make install". This takes a while so remember to give your VM a few CPU cores then use them in the jobs argument. Open up the DarkRadiant binary, you should find it in /usr/local/bin. Skip past any questions and warnings regarding the DarkMod data, you don't need TDM for this test, note that may crash it at first. As DR shows up right-click in the 2D or 3D view to take control: You should be seeing my issue as the views go all over the place. I'm sorry for the messy setup again... can understand if the team doesn't have time to bother with it, but still hope you can find a moment to try it out. The good news is once this setup is in place, you should be able to push changes to the VM and recompile (only part of the code changes) to test the result immediately. I'm happily ready to run any tests myself and confirm any solution found! Let me know if I can help with any more information.

Don't want to comment on that chatbot / spambot thing, to me it's just the latest mass hysteria created overnight to further shove the world into madness. But like I said the main reason for my idea is I find the lack of a permanent alert level too unrealistic, even by game character standards; It would be nice if this could be solved without altering difficulty but universally to all FM's. I'm just hoping there's a satisfactory way to avoid having guards literally chase you, you hide and wait 3 minutes for the whole crew to calm down, then 5 minutes after you were just being chased a guard will calmly go "what was there in the shadows, probably just the rats"... that behavior makes them almost as dumb as "chat GPT" For now I wonder: The current behavior to boost NPC acuity after a level 3 alert... is there a spawnarg to customize the amount or is it hard-coded? It would help if at least the FM can increase the offset and make a guard super-alert once they saw you. I believe another suggestion I made long ago might also be relevant: We have difficulty settings for AI sight and hearing in the menu, but could we have a third option to multiply how quickly enemies give up on searching for you? If you're impatient you could set it to low so AI forget you in just a minute, whereas if you want maximum realism have them still looking even 10 minutes later! Wouldn't be a fix to the unawareness issue once they calm down but this could improve it.

I was just thinking if a conventional depth pass may also do the trick: Render world geometry as an untextured unlit Z-buffer at a small cheap resolution (eg: 256x128 default)... knowing each entity's distance from the camera, an entity is discarded when its projection doesn't touch at least one pixel darker / further than its own location. Could that work? Something worth noting: If you own a relatively modern video card (last 5 years or so) and use an 1080p @ 60 Hz monitor, you may get the maximum performance... even that requires lower quality settings (absolutely no MSAA) but now it's possible to get a constant round 60 FPS. The big problem is playing on either a 4k or 144 Hz screen and hoping to reach anywhere near your VSync limit, god forbid both at once. Most of us don't want more pixels in our monitor so 1920x1080 is still the expected standard, unless we have TDM players who play on a large TV which wouldn't surprise me. Yet we are going for 144 Hz... once you get used to it and can't go back, anything under 120 FPS starts to feel like you're lagging. At the moment I get +80 FPS in most areas, +100 in some, +120 very rarely when I'm lucky... the full 144 only if I'm literally staring at a wall and of course in the main menu.

https://github.com/KozGit/Blender-2.8-MD5-import-export-addon This was mentioned to me on Discord. Just tried it but no matter how I install it the addon won't show up in Blender. Its description says "Blender 2.80 through 3.4" and I'm now at 3.5: Either Blender 3.5 introduced a breaking change from 3.4, or it's just for 2.80 meaning it's one of the old addons and I'm still looking. Update: Scratch that out, I was just installing it wrong. Tested and it works perfectly!

That is correct: That's the normal short-term alert level which wouldn't change in functionality. My point was long-term alert shouldn't give an AI KO-immunity directly. If it's one of the desired effects, it would make the AI draw its sword more easily, in which case it would become KO-immune during that time as a consequence.

Thanks for the clarification! I had no idea antiportals were a thing, I can't find an antiportal texture or entity in DarkRadiant so I presume it comes in another form? This means the behavior I'm imagining is already coded in there somewhere: Only change then would be automatically treating every solid brush as an antiportal, of course without having it derender itself only what's behind it... at least that's what I'd initially think, reality is always more complex. Obviously we don't check all world surfaces on the map: Visportal culling acts first so any wall that isn't in an open room doesn't exist from the start, same for surfaces that don't poke into the view frustum and are outside your FOV... if a smart approach is possible we could even check walls in order of distance from the camera so the mask masks itself and even walls covered by other walls are dropped. Only if a front-facing brush surface that wasn't portal-culled pokes into view it's calculated as an occluder; The engine then checks all entities that weren't themselves already culled by portals / frustum and removes those found to be completely covered by a wall's projection. This could be a big success is it could do all of 3 things: Hide models that don't poke beyond the mask, disable lights who's radius box is fully covered by the wall, and close portals that are fully covered by a wall meaning whole rooms can get hidden when their doorway is masked by an occluder. (Anti)portals do all of those things I believe, so it's a matter of somehow getting all surfaces to act as such in an optimal way.

Definitely no KO immunity per say, don't think that would even make sense here. The idea is for guards who have seen you to show signs of persistent awareness, behaving in a different way from how they normally act before knowing there's an intruder. Some could be mechanical and difficulty altering changes, like guards drawing their sword and searching over circumstances that would have initially made them mumble and move on... others could be cosmetic behaviors that don't much affect gameplay but add more realism, like making paranoid guards use different animations or look around constantly or randomly interrupt their walk cycle to show nervousness and confusion, which would also help the player gauge their long-term alert and know when to avoid a guard that knows what's up. Also my idea may not require a separate alert field after all. Alert levels are floats: I believe guards still patrol normally until alert reaches 1 which is "AI stops and looks around", we could activate such behaviors at say (alert < 1.0 && alert >= 0.5) then make the alert level taper off more slowly at low values (decreases fast from 5 back to 1 but very slowly from 1 toward 0).

This may have been discussed long ago on Discord and I since forgot the details. It's an option that seems so simple and effective it kept itching me to ask in more detail. The latest dev version increases performance by +20 FPS which has me excited to know more on what seems like it could be a final huge optimization. At the moment we have view frustum and visportal culling but no form of occlusion culling. I wonder how much FPS we'd gain if we also used world geometry to derender what the player can't see. Would it be worth the effort to add this even as a hidden setting to experiment with? Given it was never attempted in all those years (to my knowledge) I imagine there's a reason and I may be excited for nothing, I'm sure @stgatilov and other devs can offer more insight but I'm happy to hear what anyone thinks. Here's my exact proposal: Occlusion culling would be done after portal culling (which wouldn't change in any form) ensuring only entities and geometry in the same room are compared. Only world geometry (solid brushes) are used to mask: A counter-argument was that calculating this mask will be costly... world geometry is almost always very simple, checking a few boxes should cost almost nothing compared to the gain of hiding every light / model / portal behind any wall. We can probably iterate through all world surfaces facing the camera within a distance limit if necessary, then use the resulting rectangles to preform the same overlap calculation as portal faces but in reverse (they close behind them instead of opening); Especially now that we have entity scissors and efficient 2D detection of 3D projections this could be huge My reasoning is no matter how well you portal your map, you'll always have many entities hidden behind a wall but not a portal, the engine still renders so much stuff you can't see: To even try getting close to this level of efficiency, every single edge and corner would need to radiate portals in each complementary direction, an impossible nightmare for the mapper to even attempt which would destroy dmap if they tried (I got close with limited success). Visportals will always be the simplest and most effective form of culling, but they're ultimately markers to separate rooms and represent openings thus can't cover all situations: If on top of that we also masked by world brushes the gains could be remarkable.

Sorry for that: I try to be short but at the same time detailed and it ends up as the later. Scripting can accomplish some of this if you need it to, such a core change should of course be done in root if possible, not sure how radical it would be at this point in time though given it would involve gameplay / difficulty changes. Curious what others think and if anyone has even better ideas on the basis of my suggestion.

TDM was never meant to be fully realistic, it would become impossibly difficult were that the case. None the less I still find myself wishing more could be done to make AI feel less like AI, especially when handling hostile encounters (usually the player). While like most aspects this could never be truly perfect, one area feels like it could be noticeably improved: Giving AI some form of long term memory, rather than just one alert level which goes back to zero after a short time. Here is the reason why I'm saying this: Walk inside your average heavily guarded mansion and step into the bright lights, making all the guards clearly see you and chase after you to attack. Once you've had enough fun repeating the process, hide somewhere and give everyone enough time to cool down. At the end of it all, hide somewhere in the shadows where you can barely be seen and let a guard walk past you: The guard will just say "is there something over there", at best waiting a few seconds and saying "probably just the shadows" before walking away... the same man that may have chased after you for 30 minutes and should by any logic know an intruder is still in the house, I mean come on Now I'm aware we have a basic persistence system: If I remember correctly an AI that's encountered the player and was alerted enough to draw their sword will have its acuity permanently increased by a slight amount. This however makes no noticeable difference as the AI behaves mostly the same. They'll keep telling fellow AI an intruder is in the area, this definitely helps but it's only a dialogue change not accompanied by noticeable modifications in behavior as you'd expect. Obviously massive modifications might be hard to do now without upsetting existing players since it would make everything harder. As such any such attempt would likely be an experiment and, if successful, a new menu option for the difficulty settings. Still I felt like suggesting my imagined solution just in case there's a point in considering tackling this. My idea: Replace the one-time bump in acuity with a paranoia level independent from the alert level... think of the existing alert system as short-term alert and the new one as long-term alert. The standard alert level of guards is slowly added to their paranoia level, thus the more time a guard spends being alert and the higher that alert is the more fear increases. Paranoia level may be allowed to decrease over time but at a far slower rate than the alert level: If an alert guard will typically take 3 minutes to fully calm down after losing track of the player, the paranoia level should take at least 30 if not 60 (real life) minutes to fully go down to minimum... even then it shouldn't drop below a certain degree after that point was reached, for instance just 50% of the maximum paranoia. This long-term fear level would have several effects on an AI as they patrol on their normal route... the ones I've thought about are: Increased acuity as they'll be more alert. This system would replace the existing simple bump we have in that regard, with a more fluid effect and also stronger effect. Increased playing of voices and idle animations: Due to being afraid the guard may talk to themselves or others a lot more frequently and babble excessively. Walking could be replaced by running for a while, even on path nodes that don't have the run flag. The AI would still patrol that same route just at a faster pace. As a map feature set by FM's: Some path nodes can be filtered by fear level, may already be possible with the simple system but I never tried it. An AI paranoid the player is still around but having resumed their normal patrol route may choose to patrol a more sensitive area it normally wasn't going to, which would be a fair way of punishing the player for being seen by having that AI start guarding a sensitive location from then on. If the paranoia level is allowed to slowly decrease, the guard may decide to go back on this decision... the player could then do something else for 15 minutes around the map till the guard abandons the paranoid patrol route. Here's an idea I like: AI randomly getting scared for no reason, thinking they see the player in every shadow even when there's nothing there. A scared guard normally walking on their patrol route would randomly become alert for no reason, typically when walking through a dark area, causing them to draw their sword or randomly run around for a second. The problem here is this effect would be random: Imagine you're hiding accordingly but a guard randomly freaks out and bumps into you, most players would find this unfair.

Oh wow: Areas in my city I clearly remember yielding 60 FPS from some positions / angles now reach well over 80 FPS with latest dev, same quality settings just the new optimizations and defaults. While it was commonplace to get barely over 60 FPS in many zones, I barely found a spot where it now occasionally hits 69 FPS for just one frame You've truly worked miracles with those optimizations. Didn't imagine even more performance could be squeezed out of the engine by software fixes alone. Haven't tested broadly but they'll be felt on every FM for sure. Thank you lots!

Almost can't believe that's TDM, only recognized a few of the assets. So amazing, can't wait for this to be out!

I tried playing with the obvious things there but nothing seems to work; Adding a "return" at the beginning of those functions can stop the camera from moving at all but that's about it... when the view is engaged the pointer always moves in the background, capturing and holding it in place is what's universally failing. If this is in any way relevant, the pointerMode variable always has a value of 15 both in X11 (working) and Wayland (when the issue occurs). A reminder: When using "GDK_BACKEND=x11" the 2D view at least works well initially but experiences the same issue after selecting the clipper tool (X key by default). Can anyone think of anything only the clipper is doing to the XY window that could be used as a lead to understand what's happening?

Thanks... that's awesome, will gladly keep it in mind. Can't avoid needing a custom script but I cannot complain: I'll likely write a custom map entity for this, can use it to do both storing and triggering based on circumstance. Since I already asked, I kinda had a part two to my question: Is it possible to change AI definitions in realtime, so for minor changes you don't need to register a different AI altogether? Namely the model, skin, head definition, and voice; Can a script replace them? For the body model / skin I think that would work like on func_static, but def_head and def_vocal_set are probably read once on map load and not updated in realtime. It would also break precaching and cause a jitter. Problem is that if I leave the unused AI in a hidden box on the map, it's still loaded in memory and thinks thus wasting CPU. Can I at least delete an entity I don't want safely? The difficulty filter does that, entities not corresponding to a given difficulty are erased... this however is likely decided during loading which wouldn't work here.