stgatilov

With very recent code changes, all the resolutions are handled uniformly. In order to add a new one, you have to add its resolution and "aspect ratio" code into VideoModes array. Note that "aspect ratio" is just a way to group modes, it does not matter if the resolution has correct ratio mathematically. Of course, you also have to update string for GUI settings so that you could set the new resolution there. If you add new aspect ratio, then you have to add a new choiceDef for it, like Screensize21to9. Simple copy/pasting and fixing everything carefully should be enough. The only thing that should be kept in mind: try to avoid adding too many different aspect ratios! If you ask me, I would definitely merge 16:9 with 16:9 TV. If 21:9 is only a marketing term, probably merge it with 21:10 too. UPDATE: While looking at 4913, I found that actual view params calculation are still based on r_aspectRatio (see idGameLocal::CalcFov). So aspect ratio is not only grouping yet. But this code definitely won't survive long

Could someone explain why do we need to fix this? I have never heard any complaints about TDM exe not having proper version embedded. I hope Grayman could say better if there were such complains. And the common idea is to avoid platform-specific stuff unless it gives some noticeable benefit. Stuff like resources, manifests, registry, etc are platform-specific and unnecessary. Right now the normal way of checking version is: 1) Run TDM. 2) Look at the version at the bottom. 3) Also you may look at the very beginning of the console messages. Using step 3, it is even possible to automate checking version, although I'm not sure if it provides any benefits.

Thanks. You forgot "2". This is LGPL v2.0. It seems to be compatible with GPL v3 which TDM source code uses. To be honest, I did not spend much time with it. I checked that I can follow the position when the guard goes from left to right. And that was all But front-vs-back and on-the-side positioning was not clear. I think I'll ignore these specialized GRTF datasets until I (or someone else) integrate it into TDM.

First of all, thank you very much for the explanation how to load custom HRTF. Perfectly done. One interesting question is: what is the license for HRTF data? We have incorporated KEMAR data into 2.07 release, but I could not find any info about whether it is legally allowed or not. I just hope that if OpenAL-Soft distributes it, then most likely we can too... The same question applies to IRCAM datasets. I would be happy to include all those HRTF profiles into TDM and allow player to choose one in-game. But I'm not sure that redistributing them won't cause legal issues. Yes, but with only two speakers you are anyway doomed to have weird 3D sound, don't you? The HRTF would work as some sort of substitute for "crossfeed level", without which sounds are too easily going to one speaker only.

Could you please be more specific about "incorrect filtering" ? I think I tried both setting no value and hrtf = auto in alsoft.ini, but it did not enable HRTF for me with headphones plugged in.

The AMD CPUs calculate it differently --- that's for sure. Specification does not define the result precisely, it only says "relative error must not exceed 2^-11" or something like that. It may turn out that AMD implementation is more precise. Or it may be that the particular triangle causes problem only when the error has very specific value. So when you reproduce it on Intel CPU, then you see the problem because they all use the same circuits for it. And when you use AMD CPU, it is not reproduced in this particular case. But you can create some more stairs with such CPU and find another example of the same problem, which will be present on Ryzens but absent on Intels.

All the credit goes to Duzenko, he did the hardest part I only fixed the bad code which I wrote for 2.06

I have put full TDM 2.05 distribution at this address: http://tdmcdn.azureedge.net/release205/. I guess I will write instructions about how to use it at some moment after 2.07 beta starts. I have a question about installer. Is it enough to put a download link for the installer on the website? In other words, I think it is not necessary to change the packaging process, right?

I suggest filing a feature request. The problem is that openal-soft reads its own config inside its implementation. I have no idea yet if it is possible to set this config programmatically.

It seems that the SSE version of InvSqrt was not precise enough. I have supposedly fixed the problem, watch for this kind of issues in the future 2.07 beta.

It would make sense if mapper by default grants TDM team license/permission to modify his map in case of his absence during X years --- if he wants it to be included into the in-game FM downloader, of course. It is probably better to require such a license grant if someone wants to distribute a mission the common way. To be honest, I thought there was already some rule about changing FMs if author is unavailable. Or there was not? Isn't there any disclaimer that "by submitting the FM to mission archive you agree that ..." or something like that? Personally would prefer to force mappers to release their FMs under the same license as the core assets, so that anyone could modify them if needed. All those licensing issues... dealing with them will bring the doom upon us in the end. Do not play with devil. I believe that the process of releasing a FM to be available in-game goes through some centralized place, so whatever rules can be enforced at that moment. Without bringing your lawyers.

Always keeping up with unstable branch means always having savegames broken. I have started NHAT several times on various versions, and never got to the end of first mission. And they say there is a second mission after it...

I was just trying to show you how easily the things could result in the particular situation. No evil intent, no disrespect to other people and their work; just carelessness and lack of thought. That's why I vote for comminuty guidelines to be strictly against copy/pasting. Making it clear and well-known that everyone is strongly against any type of copy/pasting (without prior agreement with author) would convince everyone that this "shortcut" is not an option. I don't tell my students "copy/pasting solutions is bad, and you understand, we are all grownups here...", I tell them "we consider copy/pasting as going against our trust, and so we punish it increasingly hard without second thought". And these are students in 3-5 years of university, they are older than a TDM mapper could potentially be. And I vote against any technical/legal things like encryption or different license.

As a programmer, I don't mind pieces of my code to be reused without any permission/tribute. And many programmers do so. But programming is technical thing, not an artistic one, and nobody sees the code when running the program I see that the question is much more sensitive for artists. One objective reason to discourage copy/pasting maps is that it leads to lack of variety in FMs in the end, which is not good regardless of what we feel about it. Looking through the beta thread, Bikerdude really said that the copy/pasted sections are going to be changed. But somehow he (i.e. Bikerdude) forgot to do so. I think it would save a lot of nerves if (copy/paste + modify) without getting prior permission was simply forbidden: this path leads to issues too easily. Given that all of us are separated from each other by a monitor screen, such issues often blow up. Or it was intended that the original FM author had to change the copied sections? Oh, that assumption was a serious mistake! I had one such story on my job. I created a branch and temporarily uncommented one ifdef in build script. Then I handed the branch over to my collegue, who finished work and merged it back to trunk/develop. Without rolling back my temporary change, since he did not knew about it As a result, the CI server blew up and stopped working for several days. Luckily, we never talk with the guys who had to fix all the mess, but we got some negative feedback indirectly And we had to change things so that no one needs to comment/uncomment that ifdef anymore.

Thank you everyone for your answers! I have nuked darkmod.cfg and started from scratch, and it works well now. In fact, I have reinstalled drivers, rebooted machine several times. Moreover, I had two separate 2.05 installations, and both of them failed in same way. In one of them I started TDM 2.06 executable also, which most likely corrupted cfg file (changed e.g. normalCompression). Although I don't know why the second installation did not work Anyway, that was my fault. Sorry for bothering

I am experimenting with TDM versioning and updates, and have problem with TDM 2.05. When I run it, it has very weird graphics: bumpmapping is absent, and lighting is rather weird in general. Here is the screenshot: I recall that I ran TDM 2.05 during TDM 2.06 beta phase and later, and it worked properly. I am 80% sure that I have correct packages and they did not change. However, I updated video driver for my GeForce 1050ti, and I suspect that this is the issue. I wanted to ask someone who still has TDM 2.05 and NVIDIA hardware to check if it works well. Or maybe someone else can help me diagnose the problem. I need to know whether my current TDM 2.05 installation is buggy or not.

I suggest to continue discussion about distributing alsoft.ini in the thread dedicated to HRTF.

Starting from 2.06, TDM uses OpenAL as the only way to produce sounds. Moreover, on Windows it uses OpenAL-soft bundled into ExtLibs.dll. It seems that by default HRTF is off. I have an idea to enable HRTF by default. It is a matter of distributing alsoft.ini and two hrtf data files alongside TDM (outside pk4 files). Of course, it would most likely work only with headphones (although you can force it in config), and only with suitable sample rates (although you can also force it in config). For other cases, HRTF will simply not be enabled. Aside from that, I'll set cf_level to 2 for the case when player cannot load HRTF for some reason. This is also going to resolve 4898. Are there any downsides? P.S. I have enabled HRTF with default dataset on SVN.

As far as I remember, taaaki is not the first one who hosts TDM server. As long as someone controls thedarkmod.com domain, it is always possible to migrate to new hosting without changing urls. You can of course create an ini file, but wouldn't it make your installer as complicated as tdm_update current is (in the very end)?

I have disabled the optimization on SVN, the problem is gone.

Yes, most likely we should make it easy to tweak alsoft.ini. Right now it is loaded in order: 1) From global settings: %APPDATA%\alsoft.ini or another location on Linux. 2) From alsoft.ini in the path where executable file is located. In case of TDM it is the root directory of TDM installation. 3) From the path specified in ALSOFT_CONF env. var. I think distributing the default configuration file near TDM executrable is the right way to go. It is OK to set cf_level in the distributed ini file, but it won't affect anything if headphones are not detected. And I don't think it should, since the tweak only makes sense when you have headphones. The better approach would be to log somewhere whether headphones are detected or not and explain players how to override it. Another approach is to add a setting in the main menu "headphones" with values "auto" / "yes" / "no" and propagate this setting into OpenAL.

I think the old cvars no longer work after switching to OpenAL. OpenAL has its own ways of fixing the problems. They are: 1) HRTF, controlled by hrtf. I can be enabled by following these instructions. 2) crossfeed, controlled by cf_level. It can be enabled in alsoft.ini just as hrtf. Also all of this depends on whether you use headphones or not (stereo-mode in the ini file). It seems that crossfeed closely corresponds to what s_minVolume did previously. And HRTF seems to be an even better approach. Moreover, it seems that HRTF should be enabled by default if OpenAL sees that you use headphones. It least it looks like it from the default openal.ini contents. I'll try to play with it and see what has to be done to enable HRTF.

Sounds great! I think that the current location of updater can be hardcoded. For instance, the location of tdm_mirrors.txt file is hardcoded inside tdm_update: const char* const TDM_MIRRORS_FILE = "tdm_mirrors.txt"; const char* const TDM_MIRRORS_SERVERS[] = { "http://mirrors.thedarkmod.com/", "http://www.thedarkmod.com/update/", "" }; So tdm_update goes to hardcoded paths to download tdm_mirrors.txt if it does not have one nearby. After that it uses the mirrors written into that file. Some sort of bootstrapping here I think it's better to ask Grayman or Springheel: they can say how often the location of tdm_update.exe on website have changed over years. If you cannot find updater online, then... report error, I guess?

Yes, this is the problem of the algorithm. In the first pass it tries to find closest blocker in a rather large cone going from light source to the fragment being rendered. The blocker is searched for by sampling the shadow map texture in some vicinity. In this particular case it seems that all samples are shadowed, so the algorithm declares the fragment as fully shadowed. Here is the guilty optimization: //shortcut: all blockers in search angle => fully occluded if (blockerCnt == u_softShadowsQuality) { gl_FragColor.rgb *= 0.0f; return; } It seems that it is not robust enough. Often the search code is very large and has all samples shadowed, but if we then compute the penumbra radius, it is much smaller, and some samples during real evaluation are lit. This is sad because it disables optimization for fully shadowed surfaces

In the latest code, positive radius means "deduce radius from light source". The negative radius means just "use this value always" and is much safer. The code for positive radius is: if ( !args->GetFloat( "size", "-1", renderLight->radius ) ) renderLight->radius = 1e-2 * idMath::Fmin( renderLight->lightRadius[0], renderLight->lightRadius[1], renderLight->lightRadius[2] ); In my opinion, this is wrong. Moreover, given the number of different lights in existing TDM missions, this is a dangerous idea which may sometimes produce completely wrong results. Spooks, do you have problems with positive value only with r_shadows 2 ? Or they are present with r_shadows 1 (stencil shadows) also? This question is very serious, because we need to decide now whether we save this behavior for 2.07 or not. Most likely a problem in implementation. I have r_shadowMapSize 1024, r_softShadowsQuality 24, r_softShadowsRadius -2. I did not notice such problems. Could you write about some specific place (you can post coordinates which getviewpos console command prints) ? P.S. I have also noticed the "aas out of date" message in Betrayal mission on the current SVN. This is very strange, I think someone has to bisect over SVN history to find out when it started to happen. By the way, dmap has the ability to precompute shadow volumes of static objects, and by default it is turned on.