stgatilov

The current "gamma correction" does not influence interactions. Note that in a proper rendering engine lighting is computed in linear space, and gamma correction is done as the last step. This gamma correction converts the colors from linear space into gamma space. Then the physical monitor has the built in gamma transformation (left over from CRT times), so it transforms colors back from gamma space into linear space, and shows linear intensities. As the result, light sources with quadratic falloff look on the monitor as they look in the real world. Now with TDM I have no idea what convention is followed. But since all the math is done in additive way (i.e. impacts of lights are added), the whole thing can only be correct if all the colors are in linear space during rendering. It means that someone has to convert them to gamma space at the very end, otherwise monitor will apply gamma transformation to gamma space, and the picture will be over-contracted. As the result, light sources with quadratic falloff will look unrealistically concentrated (since they will actually have falloff with power 4.5): they light close things too bright, but have too small effect on things farther away. The new way gives absolutely no way to correct gamma curve of the actual light sources, while the old way did. Moreover, the old way was right on the conceptual level, although this correctness gives no benefit if everyone tweaks media using gamma = 1.2. The serious problem with the old way is that color banding appears on dark colors, because all intermediate rendering results (in linear space) are stored with 8-bit precision. And the common way of fixing it is simply using more precision, e.g. 16-bit floats for colors. This approach is called "High Dynamic Range", and it is necessarily used for physically correct lighting.

Tried it a day ago and reproduced the problem. Please, could someone familiar with mission manager do this? I see that I have permissions to do it myself, but since I have never done it, I would need considerable time to do it without breaking more stuff

Downloading missions in-game works fine for me (but only for exe-file which I don't restrict with Windows firewall). I have tried to copy my TDM 2.06 installation to other drive, and I can still download missions from the copy without problems. I think you should check to things: 1) That everyone is allowed to write into the directory with TDM installation. If it is write-protected or has restricted permissions, then TDM cannot save downloaded file there, and most likely reports a generic error. 2) Check that you don't have any type of firewall forbiding TDM internet access.

Yes, if we use 8-bit colors, then banding is inevitable when gamma correction is used. But hacks around ambient shaders cannot replace gamma correction.

It does not explain why there are both gamma and brightness in settings. If no one cares how image is brightened, one of them would be enough.

Are there other opinions on the problem? I guess trying to avoid color banding was the reason to tweak ambient light. Such tweak itself may be OK, but I think it cannot replace gamma correction.

The tdm_update often changes, that is the reason for having self-update. For instance, if you use the old version of tdm_update (i.e. you run the one from 2.05 with "don't let tdm updater update itself"), then you will certainly get into infinite loop. Without a doubt, you should use the newest version of tdm_update. As for the original endless loop, I have no idea what happens. You'd better download new tdm_update.exe from website, and overwrite your existing exe with it. Then run it, and hopefully you won't get into any infinite loop. P.S. In case of trouble, you can attach the file tdm_update.log. Without it we can only guess what went wrong on your end.

And is it a problem? There is already R_CheckCvars function, which is called every frame, and the monitor gamma was/is set exactly there. In fact, it checks if brightness/gamma was modified recently and computes + applies new palette to the monitor if it was.

It is already on-the-fly, just drag the brightness slider in video settings.

VC redist 32-bit and 64-bit are two different packages. You run 32-bit version of TDM, and it needs 32-bit version of VC redist. Either install 32-bit VC redist, or run 64-bit TDM executable. I guess nbohr1more should add this to description on moddb.

I got 2.5 ms with my calculator Well, that's another option. Do it in there when FBO is on, and fallback to monitor hacks if FBO is disabled. Doing anything in ambient interaction shader will result in incorrect gamma correction. UPDATE: In the end, I hope that bloom shaders will be converted to GLSL at some moment. Right now I cannot even understand which of those 15-20 assembly shader files are used...

I'm afraid I don't know well how these things are working. Anyway, two questions: 1) Are you talking about another way of specifying locations in general? I mean, it also affects ambient sounds... 2) While setting up a box volume would work for box-shaped rooms, there are many cases when it is impossible to cover two rooms with boxes so that they don't intersect. I think it was some case-sensitivity issue, probably already fixed.

No, it will not. The old versions of glibcxx have only the old ABI in it, since they had no idea about the new stuff at that time. The new versions of glibcxx have both the old and the new ABI in it. So you will be able to run both old and new applications. BTW, the tdm_update 2.06 was/is built against old ABI. The reason to do so is that it is using boost, and without switching to old ABI I would have to rebuild boost static libs, which I didn't want to. For the same reason, the main TDM code was also built against old ABI: starting from x64 branch merge and ending at boost removal. It turns out that I should have kept TDM at old ABI when I removed boost, but I did not see any sense in doing so at that moment.

Hmm... various things ranging from using the old desktop-affecting way to having the hardcoded gamma/brightness ? Does postprocessing really makes things so much slower, especially if you keep bloom to minimal ?

Most likely this is the aftermath of switching from FPU to SSE floating point arithmetic, since no one changes dmap code. If it is so, then I'm afraid there is no way of exactly returning to pre-2.06 behavior and having 64-bit version at the same time. And yes: those BSP things while dmapping brushes uses inherently unstable algorithms, so having some sort of issues in general is not surprising. If you have notable cases where this problem happens, please attach the self-contained map to #4877. The smaller the map is, the better. Also, if you manage to isolate the problem to a small map, that would be absolutely wonderful (these issues usually go away when you remove the surrounding environment).

Reverted the current SVN to old gcc ABI, so that this issue does not happen with TDM 2.07. Tracked as #4879.

Strangely, the current "soft gamma" implementation applies only to gamma setting, but not the brightness setting. If user changes brightness, then the whole Windows desktop is affected via the same SetDeviceGammaRamp winapi call. I think the easiest way to restore exactly the old look but without "it affects desktop" problem would be: 1) Remove the gamma setting in shaders. 2) Uncomment back r_gamma.GetFloat() in R_SetColorMappings. 3) Refactor a part from R_SetColorMappings which computes the 256-entry lookup table (aka palette) into a new function like R_ComputeColorMappings. 4) Use R_ComputeColorMappings and load the resulting table as 1D texture to OpenGL. 5) Change the TDM postprocessing shader so that it makes lookup in the 1D texture as its very last step. In fact, by doing this we can easily retain the old way of calling SetDeviceGammaRamp under cvar, if anyone wants it.

One reason to change gamma was #4160 (well, Duzenko probably has another idea?). The old version changed gamma setting directly in Windows, and then reverted this change back when the engine shut down. It means that if you change gamma setting in windowed TDM, then all the other windows and desktop also become brighter/darker. Even worse, if the game crashes, then the desktop is left in the brighter state until the user reboots machine. I personally hated this concept much during development, and eventually had to set gamma to 1 on developement installation just to make sure that TDM does not mess my desktop when I stop execution. I think it is a good thing if done right, but the current implementation is not right. I think yes, people want power function. In fact, the best solution is to restore old behavior (I mean only the visible result, not the means of doing it), unless everyone agrees that the new one is better. By the way, TDM already has bloom for a long time, which is most likely a fullscreen postprocessing. So if you are worrying about performance of fullscreen gamma-correction, you can just add gamma-correction to the end of the bloom shader, thus avoiding additional pass. Multi-light shader is a very experimental thing (shadow maps only, hard shadows only, etc), which is unlikely to become default in the near future. So the current default is the main thing everyone worries about. The gamma correction should not be done in any intermediate shaders like ambient/interaction, it should be done as the very last full screen postprocessing.

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).