stgatilov

Ok, here is how it works. GCC broke ABI of C++ standard library for std::string and std::list. This is perhaps the only known case when they did so, and they had to do so to adhere to new C++11 standard. While breaking ABI by default, they allowed to return back to the old ABI if wanted (in exchange for not being C++11-compliant). TDM 2.06 binaries were compiled with C++11 with the new C++11 ABI. If you have old version of C++ standard library (it is something like glibc or glibcxx or libstdc++), then you cannot run these binaries. The only way to run the new binary is to get newer version of C++ standard libs somehow and make sure TDM uses them. I have no idea if it is possible to install it in Ubuntu 14.04 and if it is allowed/forbidden to have many versions of it at once in Linux. Alternative solution is to rebuild TDM from source code. In order to build with old C++ ABI, you have to add the following line: BASECPPFLAGS.append( '-D_GLIBCXX_USE_CXX11_ABI=0' )into SConstruct file at source code root directory, and then build according to wiki instructions. The resulting binary would be compatible with old C++ libraries, so you will be able to run it. Now there are two questions: 1) Are you OK with compiling TDM from source, or should I compile tdm 2.06 for you? 2) Should we switch to old ABI in SVN, so that TDM 2.07 could be run on Ubuntu 14.04? The question 2 is mostly for TDM developers I guess. Given that we try to support Windows XP for one last time in TDM 2.07, it is quite stupid that it is not possible to run it on Ubuntu 14

By the way, do I understand right that the only effect of gamma settings now is brightening ambient light? And the formula is this: color.rgb *= 1 + u_gamma*(1 - dot(color.rgb, vec3(1./3))); I might be saying obvious things, but 1) this formula is not a gamma correction (which should be using power function) 2) correcting only ambient light without changing interaction light is not how gamma correction should work Indeed, the new way probably works as yet another way of making screen brighter, but calling it gamma is wrong. And the right way of implementing gamma is a postprocessing pass with power function (which may be approximated/precomputed with texture lookup). P.S. The way I used simple ambient was to isolate some bugs in shaders

It is not easy to build and run your code, because it needs some assets (I guess D3 assets), which e.g. I don't have. So debugging this requires would considerable effort from TDM coders. Maybe videos with the problem will help a bit. Looking at the sources, I have not found where crosshair is computed. I see tracer.h/cpp which seems to be used to draw projectile paths. Also I found some relevant code in idWeapon::Event_LaunchProjectiles. In projectile launching code I see: idVec3 view_pos = playerViewOrigin + playerViewAxis[ 0 ] * 2.0f; // Muzzle pos for translation clip model only-- For barrel Launched projectiles ... if ( barrelLaunch || tracer || beam ) { // Do not execute this part unless projectile is barrel launched or has a tracer effect. gameLocal.clip.Translation( tr, view_pos, view_pos + dir * 4096.0f, NULL, mat3_identity, MASK_SHOT_RENDERMODEL, owner ); It looks like this trace is always launched from view position. There is some code to correct it later: idVec3 &launch_pos = view_pos; ... if ( barrelLaunch ){ launch_pos = muzzle_pos; } But it seems to happen after the first code segment, so probably it does not have effect. Anyway, it would be great to know where crosshair is computed.

I'd like to remind to coders a few simple ideas: 1. Never make massive reformatting just because you like to do so. If you want badly to reformat many files or huge files, discuss it on dev. forums beforehand. 2. Never commit huge reformatting changes along with other changes. Also, do not mix refactoring changes which should have no effect with serious changes which influence the game. 3. Thoroughly review all the changes that you commit. If revelator did this, a lot of the issues beings complained about would not happen. 4. Do not delete or change the code if you don't understand what it is for. 5. We planned to make 2.07 a stability release. The reason for this is that TDM 2.06 changed too much and broke too much, and if we continue to do so every release, there would soon be no game to play. So please avoid any big code changes, or any changes with vast influence on the game. Bugfixing is encouraged. 6. I would agree that changing NULL to nullptr is a big change which achieves nothing. There was no need to do it, but it is the least things to worry about now.

Cabalistic has set up an AppVeyor CI, which runs build on all configurations (both on Windows and Ubuntu) every week. You can look which revisions it built successfully on its page.

Fixing warning in third-party libraries is not a good idea, since you usually don't control them (and next library update will revert all your fixes). Better reduce warnings level or use pragma warnings to remove them. Starting from TDM 2.06, all third-party libraries are compiled as a part of ExtLibs, so we don't even suppress any third-party warnings now --- ExtLibs is almost never recompiled, so they don't bother anyone. I hit this issue on my work machine. The problem is caused by Spectre/Meltdown mitigations, which break profiler driver on Windows 7. You can disable these mitigations (leaving your OS vulnerable to potential Spectre/Meltdown exploits) to make profiler work. More details here (or here).

In case user system does not support the fence, the finish call is used. It is slow, but it works at least. One possible use for the cvar is to make it easy for us to emulate such conditions on our GPUs which have fence support and normally will use it.

Tested on Windows 7 32-bit in virtual machine. The installer by default chose directory in Program Files, which of course was not allowed to be accessed initially without admin rights. After installation, I the access it granted (I see it in Security dialogs, I can edit the txt files without UAC intervention, tdm_update downloads files there properly). So this part works for me. 32-bit version was downloaded, but not installed. Also, it is the wrong version: it is named vc_redist.x86.exe and has size 14 MB. The installer downloaded by tdm_update is named vc_redist.x86.exe and has size 6 MB. In fact, your installer is for MSVC2017: it will work for 2.07, but won't work for 2.06. I have no steam in my VM. Aside from that, all files are downloaded properly. Unfortunately, I cannot check anything in-game. The shortcuts are created on desktop, and point properly both to the game itself and to updater. The uninstaller works properly (it removes the whole darkmod directory).

Issue 4531 is waiting for someone brave enough

I'll test it in the nearest future. Note that tdm_update is expected to install VC redist package by itself, so theoretically this step is unnecessary in your installer. Although I'm not sure how well it works now --- I plan to test it on clean Windows VMs. Some duplication on this part won't hurt. Anyway, please don't call this part "Install Visual C++", because "Visual C++" usually means the whole multigigabyte software including compiler, IDE, Windows SDK, and tons of other stuff. I believe this thing is called "VC++ Redistributable", or just VC redist for short.

In the current implementation noselfshadows is a hack, meaning that bad consequences happen at some moment. In order to implement a 'correct" noselfshadow rendering, it is necessary (while rendering every such object) to have all shadow volumes in stencil buffer except the volumes cast by the object itself. For an efficient implementation of such feature, it is necessary to not only add shadow volumes into stencil buffer, but also subtract them. On the other hand, isn't it possible? Render all shadows into stencil buffer first, then render all normal objects, then for each noselfshadows object: render its shadow volume in "subtract" mode, then render the object to frame, then render same shadow volume in "add" mode. This is not very efficient of course Anyway, I guess it is possible to add something like forceSelfShadows, but it will probably make things even more complicated.

From iddevnet: Could someone explain me why "noselfshadow" objects don't receive shadows from other entities? It does not follow from the name, and does not follow from description.

I have changed the line locally to: return handle.IsValid() && handle.frameNumber == ( currentFrame & VERTCACHE_FRAME_MASK );Both flickering and warnings are gone (at least most of them).

Perhaps you have too much hope for these changes. It has no new capabilities compared to TDM 2.06. Just it makes it somewhat easier to use. If you point me to some particular example, I'll try to see if it is possible. But if location entity is needed for ambient sounds, then probably it makes no sense to do anything,

Ok, committed the changes to code SVN. It gives players access to 113 presets I should not forget to update wiki for 2.07.

I have got to doing a small revamp of EFX definitions (4815) There is an important question. OpenAL supports having several different effects on single effect slot. Aside from EAXREVERB, there are also: REVERB (reduced version of eaxreverb), CHORUS, DISTORTION, ECHO, FLANGER, FREQUENCY_SHIFTER, VOCAL_MORPHER, PITCH_SHIFTER, RING_MODULATOR, AUTOWAH, COMPRESSOR, EQUALIZER. Speaking solely about room settings, does it make sense to support any other effects than EAXREVERB? After reading a bit on these effects, it seems that most of they make sense only for vocal/music studios. REVERB and ECHO are the only things interesting, but it seems that EAXREVERB covers them both. Pitch modulation is unlikely interesting (recall that it is configured room-wise), and EQUALIZER is probably not that important.

I see guards disappearing every time when a bunch of ambientCache miss warnings appear. This happens randomly, but with annoying regularity. Link to video. Flicker happens near the end of it.

Why do I have a feeling that creating infrastructure for multiple renderers will have about the same impact on the code and its stability as simply moving to GL3 renderer?...

This is hard to reproduce problem, and it is completely unrelated to cinematics (I mean everything named: roq, ffmpeg, video). While playing through the mission, I also noticed some white objects (issue 4869).

Probably AL_EAXREVERB_AIR_ABSORPTION_GAINHF: It is called air absorption hf in the current effects system, and it must currently be set in millibels instead of gain. However, this does not apply to direct sound --- those should be affected by sound source settings (outside of EFX). To be honest, the more I look into EFX effects guide, the more I see that D3 integration with it is rudimentary. It does not take into account at least the following things: 1. Listener close to walls in a big room hears things differently than in the middle of the room. 2. When listener-source direct path is blocked, the sound should be very different (i.e. occlusion). 3. The sounds coming from neighboring rooms should be handled differently, including different reverb properties and setting some overall direction for them.

This is strange. I added the following code to stock mainmenu_briefing_video.gui: // #4535: this event fires up only for non-legacy (i.e. FFmpeg-based) videos onNamedEvent CinematicEnd { // Hide video set "HideBriefingVideo::notime" "0"; resetTime "HideBriefingVideo" 0; } Unless something got broken, it should do an action equivalent to end of video duration. If you have custom gui file, then you have to intercept this event yourself. Also, all sort of debriefings, campaigns, and SDK-controlled videos are not modified to intercept this event.

Created issue 4864 for removing this hotfix. Planned for 2.08, where tdm_update will get big cleanup anyway.

I think timestamps are used to make reloadImages work (only images with newer timestamps are loaded --- otherwise it would be too long). Wouldn't it be OK for players if we ensure that timestamp = -1 is never returned from file operations when file exists? Something like if (timestamp == -1) timestamp = -2 ?

Could you please explain one thing for those late to party: why the hell are timestamps important? In my opinion, I can randomize timestamps of all pk4 files to everything ranging from 2000 B.C. to year 10000. And TDM should still work perfectly after that.