stgatilov

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

Since DXT5 format with custom channels swizzling is used by default in TDM for ages, why are normal maps still in TGAs? I mean, why they were not converted to DDS when DXT5 compression was supported?

Disregard this warning about "Microsoft Visual C++ redistributable". The only case when it is a real problem is when you start TDM and it crashes right away with some dialog box. Since it is not happening to you, it is not a problem for you. Could you please tell us which version of TDM you have? Also, attach tdm_update.log file which should be created when you run tdm_update. P.S. I guess the most likely culprit is our sick server not serving some of the files.

All the three libs which I posted have debugging info, so stack trace should show OpenAL function names on crash.

Ehm... not directly. Is it too bad when you copy the wanted version over SVN package, then build, then rename executable? Repeat it three times, and you have three executables, each with its own version of OpenAL.

Alberto, could you please comment if my suggestion would help for your goal? I'm afraid that some sort of compromise is the best we could get here. P.S. When I start hearing trendy words like Agile, DevOps, etc., I usually instinctively block myself from whatever follows...

Alberto, I think we can introduce a cvar which would control warnings behavior. With possibilities: Print to console and do nothing else (like it does now). Print to console + show a few latest ones on top of the screen even with console closed (this already happens in debug builds, maybe there is even a cvar for it). Print to console + show last few, and produce a beep sound. Raise every warning to error. Errors throw exceptions, efficiently ending the current game session and going to main menu. Given the amount of already released missions, I seriously doubt we would ever have anything except p.1 as default. But we could at least recommend more annoying warning policies to mappers when they are close to finishing their maps.

You should not be so bold about it. The idea of crashing if anything goes wrong is a very good idea in general, and I think a lot of programmers do so. I do so on my daily job most of the time. It is especially right because it is well-know that error-handling code is always the least-tested and the most-buggy. But I guess gamedev is somewhat different. The particular example about missing assets is rather stupid, because assets for game engine is treated as input data. Crashing from a missing asset is like if interpreter would crash from any ill-formed source code. When a mapper develops his own mission, I guess he has missing assets most of the time, and he would be very unhappy if he could not play the game because of this. Speaking about TDM, we have tons of console warnings on any FM right now. It surely could not happen if warnings were more annoying to everyone. I hope someone would clean them one day, but it is really a problem. So the main problem right now is that obvious crashes somehow report zero exit code, right? I guess we can fix it.

It sounds like a good idea, but TDM has several interconnected services with a lot of data worth saving. You can put repository somewhere, but what about mantis bugtracker, invision forums, and mediawiki? The bugtracker, SVN, and forums are linking to each other a lot, so losing one of them would mean losing a lot of information about when, how and why something was done. Don't say that GitHub has issue tracker: it is very simplistic compared to mantis, and I bet it won't import all the mantis data in lossless way.

You can specify the URL to an XML file of specific format into tdm_mission_list_urls cvar. You can read more about it here:

UPDATE: As of November 12, in-game mission downloader works again. No tweaks/hacks required. The game has an option to store FMs on mirrors. I'm pretty sure all of them are located on mirrors. However, the game itself has no way to learn about new missions and their locations, except for ask someone else. That's why when you click "Download Missions", TDM downloads an XML file from one of the URLs stored in cvar tdm_mission_list_urls, which serves as a catalogue of all FMs available. By default this cvar points to the location on thedarkmod.com, which is not available now. So while all FMs are located on mirrors, right now TDM does not know how to get them. I have all FMs from January 2019 locally. I have reconstructed the XML file from them, and uploaded everything to my Azure storage. If you point TDM to it, then in-game downloader will work. There are two ways to do so: Execute: tdm_mission_list_urls http://tdmcdn.azureedge.net/fms/missionList.xml in game console. Then click Download Missions, and it will use my catalogue of FMs. The downside is that TDM won't remember this, so you will have to run this console command every time you restart TDM. Add +set tdm_mission_list_urls "http://tdmcdn.azureedge.net/fms/missionList.xml" to command line parameters of TDM. You can do it by taking or creating TDM shortcut on desktop, then going to its properties, and adding the underlined string after TheDarkModx64.exe. The downside is that you should not forget to remove this parameter when the TDM server is back online. Note that this is only a temporary emergency solution, and it suffers from some issues: Mission details and screenshots won't work. They are stored only on TDM server, so I have no way to reconstruct them. Release date is missing. Titles may be wrong/weird. Localizations are missing. Perhaps I can upload them too, but I tried to keep it simple. Sometimes you are allowed to download an FM you already have. This is caused by some TDM deficiency IMHO: the codenames are obviously matching. Some FMs may be outdated, recent missions are not available (the snapshot is one year old). Download speeds are not very good. Clouds are slow. So be patient ? P.S. If you use this way, then you will download FMs from my storage, and not from the original mirrors. I would be glad to point you to the mirrors, but I can't: their locations are stored in the XML file which went offline ?

I have found that browser is the only RAM-consuming feature on a typical PC (and on my PCs most of the time). I think RAM manufacturers should pay money to Google for ongoing Chromium development ?