stgatilov

These are the parameters which express "gain". All of them are converted between TDM and OpenAL the same way. In OpenAL, you specify the gain factor F. It means something like "the loudness of this thing is F times greater than the generic loudness of the sound". So, it is just a plain ratio between two volumes, i.e. the sound pressure. In TDM, you specify things in millibels, which is 1/100 of decibel. Decibel is logarithmic value typical to measure difference in sounds volume. Here is the conversion: each 2000 additional millibels increases gain in 10 timeseach 200 additional millibels increases gain in pow(10, 1/10) = 1.258... timeseach 20 additional millibels increases gain in pow(10, 1/100) = 1.0232... timesFor example, -2000 millibels converts to 1/10 gain factor, -4000 millibels converts to 1/100 gain factor, and -6000 millibels converts to 1/1000 gain factor.

I have already made changes in SVN, so that "reloadSounds" command reloads the EFX file too. So unless it gets into the "missed the train and has to wait for the next train" category, I hope it would be in 2.06 This is correct, according to what I see in the code. No idea why "Version 1" is necessary, since no other version number is accepted This seems to be right. When you specify a parameter, TDM asks OpenAL to take it into account (using alEffectfv method). When you don't specify it, or you specify wrong value, then TDM simply does not tell OpenAL about it. Most likely OpenAL takes default value in this case. If you specify wrong value, you will see a warning in console. Well, I can try to explain how to read official docs on these values. First of all, open page 66 of Effects Extentions Guide of OpenAL. Here you see the table of parameters for AL_EFFECT_EAXREVERB. They are mostly the same as the parameters described in EFX file, with two differences: Names are a bit different. Everything starting with "reverb" maps to LATE_REVERB, some names without last word map to GAIN (e.g. "reflections" maps to AL_EAXREVERB_REFLECTIONS_GAIN), "room" maps to "GAIN", etc.Everything looking like "gain" must be specified in millibels in EFX file, while in OpenAL EFX they are described by gain factor. So keep in mind that values are quite different for such parameters.And for code-literate geeks, here is the exact code which converts EFX file parameters into OpenAL EFX parameters: I hope this would help to write better docs.

Maybe we should write GLSL version header in EVERY shader file to make sure this does not happen again?

Yes, this is exactly the change. Previously (e.g. 2.05) all ID_INLINE functions were marked as __forceinline, which made compiler always inline them unless it is impossible. Now (2.06, trunk) all ID_INLINE function are marked as __inline, which tells compiler to decide whether to inline function or not. These two options are very different and affect the code quite a lot. But even I cannot believe that this change can make a 2x difference. It is more related to graphics, I think. Anyway, by "profiler data" I think Duzenko means to actually run profiler and send profiling results. You need to launch MSVC, choose Analyze->Profiler->Attach and choose running TDM process. It is very desirable that you have the PDB file from that build (if it is thrown away, then profiling/debugging release binaries becomes impossible). If you don't, you have to build executable locally, and then do it. In the results, you can see where TDM spends CPU time. If the problem is on CPU side, it should be noticeable. And of course this can only be done by developer, no one expects a normal player to install MSVC

Let's for now stick to the hypothesis that the skyrocketing RAM is actually a memory leak and that it is completely unrelated to dmap issues. The fact that dmap in 2.06 fails should not cause high RAM consumption of TDM engine on the map dmapped by 2.05. It is rather illogical... Is there any clear way to reproduce the leak? Or any ideas where to search for such a way?

If dmap tells you "brush A on entity B is unbounded", then A is the primitive number. B is most likely zero (i.e. worldspawn). So simply find "// primitive A" in the map file, and remove it. In your case dmap chokes on brushes 10354, 10471, 10487, 11034. I think the brushes do not really have infinite size, but dmap fails to compute their faces properly. Yes, this is also a possibility.

Your machine does not like compression These messages show that TDM starts repacking tdm_gui01.pk4, because it has video briefing_video.roq inside it and TDM wants this file not to have compression. However, the repacking process fails: MiniZip meets some problems with reading video/briefing_video.roq from your original tdm_gui01.pk4, so it returns an error. After this error, the pk4 becomes unavailable for the current game session. Most likely this means that tdm_gui01.pk4 was corrupted, although I have no idea why. Probably the updater also looks inside the corrupted pk4 and cannot make any sense of it? This happens at the end of savegame process, when the whole savegame data gets compressed with zlib. Zlib's compress function returns Z_BUF_ERROR, which is hard to explain especially in x64, unless your savegame e.g. has size more than 2 GB. Of course, disabling tdm_savegame_compress would remove it, but would your savegames load properly after that?... This is very weird. This comes from script self-checking code which I added when I tested scripts under 64-bit platform. You can see the calls in tdm_base01.pk4/script/tdm_player.script in player::init method. The counterpart from TDM engine can be seen in game/Player.cpp e.g. in idPlayer::Event_TestEvent1. These calls are performed on game start and they simply pass some data of various types to TDM engine and get some data back. Whenever TDM engine sees a mismatch, it prints the error message you see. I have no idea how this message can appear on one machine and not appear on another one, given that both use the same executable file. And I guess there are other beta testers on Linux here, and they do not see this error. You can of course comment out the code in tdm_player.script, but even if the game starts, you will most likely see errors and corruption on every step without script events working properly. I don't like saying this, but did you try stress-testing your RAM and CPU?

Yes, you are right. Starting from 2.06, all whitelisted video files and ogg files are stored inside pk4 without compression. This is absolutely necessary for FFmpeg video playback and improves loading times for ogg sounds. Since there are three completely independent ways of delivering pk4 files into player's installation (one of them is not even controlled by the TDM team), the TDM game itself has to make sure that pk4 archives are packed properly. Whenever TDM engine opens a pk4 file, it checks if compression is good, and repacks all the pk4 which don't adhere to the new TDM rules (i.e. which contain compressed ogg/video file). Every time you launch TDM, it usually repacks all sound/video pk4 and the pk4 of the installed FM (if it was not done before). Unfortunately, this change is quite hard for tdm_update, since no one ever thought about changing compression level without touching data. The new version of tdm_package would create full pk4 packages already with new compression rules applied. However, the beta package is still created with the old tdm_package version, which simply compresses everything. Obviously, your local pk4 files become different from server ones after you launch TDM at least once. After that tdm_update thinks those pk4 are wrong and downloads them again. We are currently waiting for taaaki to update tdm_package on the packaging machine. After that, I hope, tdm_update won't try to download those 700 MB again and again.

Just fixed the problem in SVN, hopefully the fix would get into the next beta package. You could really see less sparklies previously on SVN, because in October specular exponent was bumped from 3 to 5, making this issue more severe.

Could anyone please create an issue about it in bugtracker (or bump an existing one, if it is already there) ? Please write down steps to reproduce so that even a non-mapper like me can understand and complete them (maybe with links to wiki about dmap/map commands, maybe with examples of map files from SVN). Probably Springheel can do it nicely for us, "mere divelopeers"?

If you simply replaced .roq-file with .mov-file, then you have not tested the feature completely With some additional setup, you can make TDM play both video and sound from a single video file, and you can make TDM end the cutscene at proper time without specifying length explicitly. I have just wrote a wiki article about new cinematics. P.S. Also note that .mov file won't play properly from inside .pk4. We have a whitelist of things which "are not to be compressed", currently it contains only mp4, m4v, avi, and roq.

I believe there is no way to use anything but embedded software renderer of OpenAL, and I guess it is good because it avoids any hardware issues. As for devices, the default one chosen by OpenAL is usually used. You can change device by setting its name to "s_device" CVar (see the beginning of console for OpenAL messages), although on my installation the reported names are very long and contain undisplayable russian letters, which makes it completely impossible to specify their names. If you successfully set the name of a device to s_device, then you should see "(ACTIVE)" near that device in console. Could you explain what is the benefit of being able to choose another device?

As before, the setting is linked to s_useEAXReverb cvar. As before, this cvar controls whether "efxs/[mapname].efx" file is loaded with the respective definitions. If you set the cvar/setting to 0/off, then efx settings won't be loaded at all. P.S. I have noticed a bug that when I enable EAX 4.0 HD in GUI, it shows "changes would take effect after restart" message, which I cannot close. Each time I click on OK button, the message pops up again immediately after it disappears.

Do I understand it right that this effect is only applicable to an absolutely horizontal floor? Also, can't it be implemented as a mirror instead of floor with some sort of addition (transparent geometry on top)?

You cannot use MSVC community edition anonymously at all. It has 30 days trial, after that you either login with your MS account, or you don't use devenv any more (cl.exe compiler still works I guess). That's how things work since the very first community edition, I suppose. P.S. I think upgrading MSVC would be a good idea after 2.06 is finished. MSVC 2015 has several nice features I know about.

First of all, the code of 2.05 is very different internally from the current SVN version (and future 2.06). So it is not clear how useful the patches against 2.05 would be. Second, I imagine the main problem would be with third-party libraries: prebuilt binaries for MSVC2013 exist in SVN, but you have to build MSVC2017 binaries yourself. Finally, you can still download MSVC2013 community edition without any problem. Of course, you would see MSVC2017 on the front page of every MS site. MS is pushing everyone to the latest version: if you use it for free, then you could at least do some testing for them, right? That's a very reasonable policy.

I just committed the fix in SVN revision 7215. Although I don't expect the multithreaded renderer to work under Linux.

I thought that's the main point of BFG-style VertexCache. That's a good question. I'm not so sure that CPU processing time really matters. You can probably disable DeriveTangents/NormalizeTangents after 500-th frame, and see if FPS improves. Then try disabling all VBO updates and look at it. This way we can finally see what is the bottleneck of these two... Doesn't access flags tell driver that mapping is also one-way? (e.g. GL_MAP_WRITE_BIT | GL_MAP_INVALIDATE_BUFFER_BIT).

With com_smp enabled, I do not see the menu. If I enable it only during playing a mission, then console starts jumping up/down, then some weird text appears (font texture, I suppose), and finally everything crashes. Actually, it crashes the whole Oracle VM, not just the TDM process Making sure com_smp is always 0 on Linux is one way to go. Unless someone knows enough about how OpenGL interacts with Linux OS.

It is great to hear that VertexCache is ported from BFG. When you checked performance, I hoped you tested some level with many guards visible Perhaps the new version should be profiled to check again what is going on. There is another problem related to your threading changes. Linux version currently does not link with the following error: build/release/core/framework/Session.o: In function `idSessionLocal::FrontendThreadFunction()': /media/sf_TheDarkMod/tdm/framework/Session.cpp:2990: undefined reference to `GLimp_ActivateFrontendContext()' collect2: error: ld returned 1 exit status Apparently, someone must implement this function with glx calls.

I think Linux distributions are so much different between each other, that having perfect installation instructions is not possible. Luckily, Linux users are much more capable of handling any issues than a typical Windows user. The release 2.06 will probably include native 64-bit version (unless it drops dead during testing), so the amount of trickery required to run TDM on a typical Linux OS should decrease. Me too

I think the current approach with OpenGL is: we use something very old like version 2.1, and we enable extensions for anything relatively modern (like e.g. framebuffer). If you need a fence, there is no problem in using it via GL extension. Just make sure that when cvar for multithreaded rendering is disabled (I hope it is already present in the code?), this extension is not required. In such case people with old video card can still play the game without issues.

Among other problems: Apparently, com_fixedTic has no effect now: the framerate is always unlocked. My GPU whines about it =) Debug rendering flickers. Check g_showCollisionAlongView or any other stuff which draws debug lines over the world. I see visual glitch with some weird text when I start new game: at the moment when "click attach to start mission" window appears.Also, I have seen crash inside GLimp_SwapBuffers, but I believe it was caused by Fraps. As for FPS in release build, it increased from 60-70 to about 120 (well, it constrantly changes) in Inn Business for me.

For me it crashes most of the time when ROQ starts playing on mission start. Sometimes it also hangs. Sometimes it works as expected (rarely). If I revert duzenko's commit, the issue disappears. I have logging enabled for ffmpeg cinematics (set r_cinematic_log 1). Here are three possible call stacks: > TheDarkMod.exe!idBTree<idDynamicBlock<char>,int,4>::Remove(idBTreeNode<idDynamicBlock<char>,int> * node) Line 199 C++ TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::UnlinkFreeInternal(idDynamicBlock<char> * block) Line 754 C++ TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::AllocInternal(const int num) Line 610 C++ TheDarkMod.exe!idDynamicBlockAlloc<char,262144,128>::Alloc(const int num) Line 468 C++ TheDarkMod.exe!idStr::ReAllocate(int amount, bool keepold) Line 88 C++ TheDarkMod.exe!idStr::EnsureAlloced(int amount, bool keepold) Line 305 C++ TheDarkMod.exe!idStr::idStr(const char * text) Line 367 C++ TheDarkMod.exe!idStr::Replace(const char * old, const char * nw) Line 673 C++ TheDarkMod.exe!idFile::Printf(const char * fmt, ...) Line 271 C++ TheDarkMod.exe!LogPostMessage(const char * message) Line 70 C++ TheDarkMod.exe!LogVPrintf(const char * format, char * args) Line 102 C++ TheDarkMod.exe!LogPrintf(const char * format, ...) Line 108 C++ TheDarkMod.exe!idCinematicFFMpeg::ImageForTime(int milliseconds) Line 915 C++ As far as I understand, logging starts to use idStr-s concurrently, and they are allocated via string pool (stringDataAllocator). This string pool is based on idDynamicBlockAlloc, which is not threadsafe, hence weird crashes in random places. I'm pretty sure that other logging functions can be affected, even trivial common->Printf can crash in the same way. Also, I'm interested if there are other places where idDynamicBlockAlloc is used concurrently (there are a lot of them over the code). Finally, I'm not sure that idHeap is threadsafe, and it is used by lots of code for memory allocations (not to mention that all new/delete calls can be redirected to it with ID_REDIRECT_NEW_DELETE).