stgatilov

How many physical cores do you have? TDM fully uses two threads, plus some minor time is taken by async thread and OpenAL mixing. If you have two cores, then it is not surprising that OBS cannot find processing time. Also there is "Frontend Acceleration", which assigns some job for more threads, probably you should disable it. Did you try setting high priority to OBS in Process Explorer ?

Do you say it does not happen without OBS? Is it well-reproducible (slows down on same location)? Did you try different recording mode (e.g. screen capture) ? Is it on Linux or Windows?

Would you mind if this discussion about tooltips/hints is transplanted into a separate thread? I see it goes long way and has nothing to do with dev builds.

I'm not sure this is a good idea. It would turn TDM into something like in the "What if Quake was done today" video. I think it is OK only for educational/training FMs. We only have New Job and Training Mission yet, but it would be great to have a few more small ones...

I imagine the following problems: The code in sys/ which is written for Linux probably needs rewriting. That's the hardest part. Clang might not compile something in TDM. Hopefully it is just a bit of simple fixes. Third-party libraries are not stored for FreeBSD, but you can perhaps build them via "custom platform" way. Although they can fail to build too... So I wonder how you handled these parts.

The latest dev build (dev16215-9215) includes many changes in dmap: 5562, 5488, 5486 The main goal of these changes is to make dmap faster. In most cases it meant writing a faster version of some small piece of code. There is one major exception: I had to write a brand new algorithm for optimizing polygon triangulations (~1200 LOC). I used two well-known FMs to track progress. Here is the total time improvement: Painter's Wife (city): 8:10 -> 1:28 No Honor Among Thieves (politics): 4:35 -> 0:30 You should expect less improvement on other maps, since these two are rather outstanding cases. The nhat/politics map was very slow to compile due to a bunch of stalagmites: they generated hundreds of thousands of triangles, which caused slowdowns in several places all over the code. And the painterswife/city is... just too big although I guess it has some local bottlenecks too. Of course, with such massive changes there is always a chance that something breaks. The worst part of it is that dmap was never perfectly reliable to begin with: it just used to fail rarely enough, and hopefully this trend continues. While I did test new dmap on some existing FMs, I didn't have much time to check the outcome. So more widespread testing would be appreciated! In case something does not work, there are cvars which can disable most of the changes and switch back to the old code. There are a lot of them, and all of them start with "dmap_". Toggling them individually is not fun, so I suggest using the new meta-cvar dmap_compatibility. You can set it to the version of TDM that you want to emulate in dmap: dmap_compatibility 207: legacy mode dmap_compatibility 208: enable major changes related to visportals and opacity (shipped in TDM 2.08) dmap_compatibility 210: enable dmap optimizations too (to be shipped in TDM 2.10, also default mode) Note: not everything can be switched back via cvar! Just setting the cvar won't give you exactly the same result as the actual old version does. But I hope the biggest differences should be removed this way. P.S. A general tip: if you could check the latest dev build from time to time (e.g. once a month) with the map you work with, that would help a lot in detecting issues early

New dev build is available: dev16215-9215 UPDATE: I have just noticed that the code revision of this build is 9224, so I renamed the version to dev16215-9224

Trying OpenAL 1.21.1: it seems this problem has been fixed. At least I don't have any issues with bsinc24 resampler. I guess I'll update OpenAL for TDM 2.10.

Most likely you have the same problems as here: As described here, you can fix the problem by finding file alsoft.ini and commenting out line "resampler = bsinc24".

Well done. Although I have a feeling that DXT1 and RGTC are different compression formats. I think RGTC is also called BC5U. UDPATE: I guess it is either BC5 or ATI2N_XY... Damn this stupid nomenclature!

I managed to reproduce the problem (maybe another one, but definitely a problem) on my machine by setting resampler=bsinc24 in OpenAL config, plus "s_force22kHz 1" in game console on start. Please try the following: Open "C:\Users\Miles\AppData\Roaming\alsoft.ini", in text editor. Find line "resampler = bsinc24". Add a sharp at the beginning of this line, aka "#resampler = bsinc24". Now start TDM again and check. If you start TDM with "run_with_openal_log.cmd", then you can later check "openal_log.txt": it must not contain the following line: AL lib: (II) LoadConfigFromFile: found 'resampler' = 'bsinc24' Most likely you will be able to set 48 KHz frequency back if you like.

Just to clarify: the sound stops from jumping on wooden surface if "s_force22kHz 1" is set. But does not stop from jumps on wooden surface when this cvar is not set, right? P.S. You might also want to disable EFX and HRTF in sounds settings, then restart game. The is some small chance that it would fix the problem.

And one more thing to try. Try to set cvar "s_force22kHz 1" in console immediately after you start TDM. Then try to play game. Does normal sounds play well? Or you get the same problems with more sounds now? In particular, do rat squeaks play properly? (e.g. at the beginning of Saint Lucia or New Job FMs)

Could you please download the attached batch file and use it to start TDM (version 2.09)? It sets two environment variables which enable OpenAL internal logging. When playing, please get to the location where this bad sound happens (or where it is missing), and let it trigger. After that, create condump, then finish game and exit. Please provide: File "openal_log.txt" in the TDM directory: it must be created if you start TDM via attached script. The condump file that you recorded. P.S. Note that you can have both TDM 2.08 and 2.09 side-by-side. Or you can switch between versions pretty easily using tdm_installer. run_with_openal_log.cmd

Do you run TheDarkModx64.exe ? Do you use Windows 10? Could you please write which CPU do you have? Which FM did you play, which book did you read? I guess the problem happens everywhere, but please bring at least one example for clarity. About the loud sound: was it some weird noise, or was it intended sound just too loud?

Yes, I recall report about such strange behavior. I have 48 KHz 24-bit setting, and never had any problems with TDM sound. Maybe there is some bug in resampler, which does not always happen. Yes, it is definitely not an installation problem: the game simply does not work well on your system. Unfortunately, it is quite likely a bug in OpenAL library. A bug in TDM is also a possibility, of course. I'm afraid the last version without OpenAL was 2.05. You can get it via tdm_installer, and it will work perfectly... but it is quite old for today. I have heard reports like "does not work" and "constant noise", but this behavior is damn strange! Definitely worth investigating. Yes, it is of course unplayable in such state. Sorry for that. Good god this is not teledildonics hardware! I don't think this sound was changed from 2.08 to 2.09. It is more likely that there is a bug which fills sound buffer with garbage data. Garbage data is an interesting thing: it can be correct data, all zeros, some infinite values, or very low values, ... pretty much everything, depending on some random factors. Whoa! That's the spirit! Unfortunately, such issues can take days to debug without any result in the end So I'm afraid you will need your patience a lot.

How does it look on a different machine (e.g. with NVIDIA GPU) ? Most likely this is the artefact of RGTC compression. If this problem does not happen on other GPUs, then it is a problem of how Intel driver compresses to RGTC. It is hard to see on a screenshot how bad the problem is, especially when "good" screenshot is not provided. The most important question is: will we have to live with such problem if we compress all normal textures to RGTC, as we plan to do for 2.10 ? To answer this question, you have to take some offline tool (most likely Compressonator) and convert this normal map to DDS. Then ensure this DDS is loaded in game (I'm not sure whether engine already loads DDS automatically or not) and check how it looks.

@Dragofer is pushing tons of customization capabilities into the security camera. And to be honest, I don't like it. Security camera is a rarely used feature. Yes, that's because it was unfinished, and it will surely be used more in the near future, but it still won't be widespread. It does not fit well in every FM, so many FMs won't use it. Players have expectations. When they shoot water arrow at torch, they expect it to get extinguished. When they see security camera, they will quickly memorize that it can be only destroyed with fire arrow, and they will expect such behavior. Customizing such things will only confuse players. I'm definitely not against customization, but I'm afraid the truth is: there will be one default, and all deviations will not be noticed by players. In the worst case they'll find customized versions confusing or buggy, because they don't work "as intended". Will you care to explain these differences to the player inside your FM? I doubt it. Cameras are not important enough for the story to talk to player about them.

Yes. Well, it was you who implemented it I guess nobody tried "r_glCoreProfile 1" yet.

Could you please clarify: Which same problem you have (one guy posted about an entirely different problem in the middle of this thread). Which solution worked for you.

@kyyrma did not respond. @Dragofer, could you please fix the FM? Preferably in DM-less way (or even DR-less)...

I'm pretty sure @duzenko only wanted to look at Windows code. @cabalistic planned to look at the corresponding Linux code (5510), possibly trying to replace it all with GLFW. The code itself is in sys\linux\glimp.cpp or close to there.

There is no point in introducing PBR if the whole pipeline is not gamma-correct (both assets and rendering).

I doubt @V-Man339 had these user-made shaders when he discovered the problem.

Hmm... the shape of this black thing might be explained by how bloom blurs light. Does disabling bloom really help to remove it once it appears? Does enabling it back restore the artifact?