stgatilov

Just committed binaries of OpenAL 1.19.1 to the code repo (svn rev 8438). Let's hope it will keep everyone happy.

Speaking short, you should definitely reset this cvar to default and enable antialiasing. You will get much better performance then

r_fboResolution is called "Render Scale" in graphics menu. Players can set its value lower than 1 on low-end machines in order to make graphics faster by sacrificing precision/resolution (image will be blurry). You have value 1.7, which is above 1, so in your case it works like supersampling --- which is a bruteforce approach for antialiasing. Most likely you got this value during 2.06: at that time things were pretty weird and some hard-to-follow settings were enabled automatically depending on other options. Antialiasing was fixed in 2.07, but you did not reset your config, hence the non-default value persisted up to this day. When you reset r_fboResolution from 1.69 to its default value 1, your GPU will have almost three times less pixels to process. So this change will definitely improve your performance (in theory, up to 3 times). But you will notice aliasing on hard almost vertical edges. In order to fix it, set Antialiasing in game menu to 2x or 4x. You can also experiment with other settings like soft shadows: it is very likely that settings which you could not run before will run normally now.

I have noticed that the big fire in the middle of the map severely decreases FPS when you look at it. Is it really so bad? Maybe @duzenko would be interested in this case...

I managed to reproduce the problem: it is caused by r_fboResolution. As a workaround, execute "r_fboResolution 1" in console, and the problem will go away.

Nevermind.

According to good issue-reporting policy, please, attach your darkmod.cfg and condump when this happens to the issue.

John Carmack only worked on Doom 3, he did nothing specific for TDM. If you are wondering who worked on TDM, better see the page on website. If you are looking for founders, pay special attention to people who started before 2009.

He is the creator of Doom 3, and TDM is using game engine of Doom 3. Simply speaking, the most important part of the programming code of TDM was written by the team led by that guy more than 15 years ago.

Lowenz reported crash on the current version of OpenAL. I guess I will update OpenGL to 1.19.1. If your problem resurfaces... I'm afraid you will have to workaround it with dsound backend ?

I wrote that they can add up. Values of r_gamma and r_brightness influence some parameters of postprocessing, so the visual effect of increasing gamma/brightness would be very similar with JCDenton settings and without.

What if we add presets to postprocessing, and apply r_gamma/r_brightness and bloom amount on top of preset? So, we can have "Null" preset which does nothing. People can use it if they don't like how postprocess looks now. The r_gamma and r_brightness values will be passed to postprocessing. Also, we can have "JCDenton" preset, which works as it does now. But still, if you have non-default r_gamma and/or r_brightness, then they modify the preset values. So adjusting gamma/brightness still have desired effect. Over time, someone may probably add other presets...

The wiki should be working again.

I tried it just now, and got the same error. Thanks for writing about it. The server is being worked on, so stuff may go up and down. Please be patient ?

I think it would be great if artists could check how RGTC compression affects normal maps and write down the worst cases. The RGTC compression should be somewhat better that hacked-DXT5 which TDM uses now, and significantly better than standard DXT5. Recall that RGTC is enabled by image_useNormalCompression 2.

It is possible to make postprocessing work exactly as the old gamma correction. In fact, I won't be surprised if it is possible right now with proper values. There are so many variables.

To be honest, I don't use default gamma and brightness for ages by now. They are OK for players only until they get the first TDM crash, after which they are left with overbrightened desktop until reboot. They are definitely unusable for developers, who frequently switch between TDM and Visual Studio. And most likely they are hardly usable for mappers for the same reason of frequent switches. In my opinion, postprocessing is a much better option. Simply enable it (r_postprocess 1) and reduce gamma a bit (r_postprocess_sceneGamma 0.65) to make stuff better visible. This does not break the desktop. But since TDM renders everything in 8-bit colors (i.e. no true HDR), color banding is inevitable, as Duzenko said. But to me personally, this is not a problem because I don't crank it high. I wonder why we can't switch menu settings GUI to changing this instead of old-fashioned gamma/brightness. Of course, it requires a postprocessing pass. As for r_ambientMinLevel and r_ambientGamma, I have mixed feelings. They definitely allow me to see dark places, which is OK for development, but they make lights weaker. I'm afraid overbright lights in overly dark streets is the visual signature of TDM game. Ironically, it is actually the direct consequence of D3 renderer being gamma-incorrect ?

But now normal maps are compressed with some DXT5 variation when they are uploaded to OpenGL. Does it mean that most of the players see those exact artifacts right now?

I have even created some issues about engine optimization specifically because of this map. There are some inefficient algorithms which never caused any trouble before, but start eating serious time here. I wonder if this map is still being worked on, because honestly I have ignored all those issues recently...

Guys, don't pay to much attention to this stupid redistributable. If it does not install, it will not cause any problems. Unless you get immediate crash with a dialog box when you start TDM, simply ignore whatever the updater is saying about it. The redistributable packages should not collide and make conflicts. You can have many of them installed simultaneously. Sometimes installing a new one upgrades the previous one: in this case everything which worked with older redist should work with the newer redist too. I have already removed dependency of TDM on VCRedist package, and removed that dreadful "Installing VC Redist" step from updater. Nobody will ever have such problems any more.

I had a feeling that when AddActiveInteraction is called, the scissors of lights are not yet computed. I see something like 0 0 63 63 there, which is probably wrong. The interactions are added/cached at this moment, and when later light sources get correct scissor, the decision about interactions is already made and does not change. When you save/load, most of the stuff is completely destroyed and recreated, and some info (like scissors of lights) remains in memory. Note that before your change, the scissor was computed somehow inside HasActive and was correct. This is just a guess P.S. Please fix 5060 also, because right now all glass materials are broken.

And the blame goes to: Revision: 8380 Author: duzenko Date: 12 октября 2019 г. 2:04:12 Message: More BFG frontend bits & pieces merged ---- Modified : /trunk/renderer/tr_backend.cpp Modified : /trunk/renderer/tr_local.h Modified : /trunk/renderer/Interaction.cpp Modified : /trunk/renderer/Interaction.h Modified : /trunk/renderer/tr_light.cpp Modified : /trunk/renderer/tr_main.cpp UPDATE: If on revision 8379 I remove the call to HasActive( shadowScissor ) in idInteraction::AddActiveInteraction and take shadowScissor as vLight->scissorRect instead, then I get this problem.

Yes, quickloading fixes the issue. And with r_showPrimitives 1, I can see pretty much every counter going up after load: more draws, more tris, more VBOs, even image memory is increased. Maybe some draw calls are lost, e.g. in frontend. UPDATE: At this moment people usually bisect. It should be possible, unless SVN was completely broken. This is yet another reason why developers should keep trunk working, including Linux build, Just imagine you have Linux build broken for 100+ revisions, and then realize that some of those revisions introduced a Linux-only bug, which you cannot bisect...

Interestingly, I don't see the problem where Grayman showed it in the training mission. But I see completely unlit pieces of walls behind "Keys and Lockpicks" and "Gamma and Brightness" doors. UPDATE: Doing vid_restart fixes those problematic sections, but breaks different places: they become completely black so that even lantern does not help. This is accompanied with GL_INVALID_OPERATION error spamming in console. I guess vid_restart is broken for a long time already, so no surprise here.

I am seeing the same issue in New Job mission, at the very beginning. Some sections of the floor are totally black, unless I enable a lantern (which lights them). Looks so weird, like if the world is partially disintegrated. Here is the video. Attached config file and console. Darkmod.cfg qconsole.log