stgatilov

Hmm... I guess I have seen the second error recently. Don't remember how it ended.

I committed the simple fix in svn rev 15746.

It is not exactly true in 2.08. We start at the size large enough to contain all static geometry, which is quite big usually. There are at least two major issues with the new vertex cache that I know of : 5066 and 5065 If non-monotonous growth is an issue, it would be third in this list

Well, TDM installer does not 'want' special installation path. It does not suggest any default. It installs wherever user puts it. By default user cannot put it into program files, and wherever he can put it, it should install and work normally. If user knows where is his user profile, he can install TDM there. The instructions on website advise to install to C:\games\TDM or something like this, if I'm not mistaken. I cannot agree with you here. These days most of Windows games install into D:\Steam\steamapps\common\... Why does Steam ignore Windows conventions you are talking about? ? I guess exactly for the same reason that we are discussing here: it is too risky to mess with Program Files, admin-protected zones, and anything else which is specific to OS. Plus the structure of special Windows directories changes every 5 years or so, with more and more junctions being added, while D:\Steam worked in DOS, works now, and will continue to work until the last of Microsoft OSes dies.

Yes, this is what I mean by switching accounts, I guess my terminology is wrong here. You cannot live without doing so, because you won't be able to install most of programs without admin rights. But if something can run without admin rights, better run it like that. The main concern I'm talking about is that when a program runs under admin, all the files it writes are by default owned by admin and cannot be accessed later without admin rights. So imagine that you have installed TDM without admin rights into C:\TDM. Then you accidentally run it with admin rights and quicksave on The New Job FM. The next day you run TDM without admin rights and continue playing this FM, but suddenly quicksaving doesn't work for you. Even worse, your game settings don't persist between launches. And that is because TDM cannot overwrite its files, because they are owned by admin, and you run the game under user. So you have two choices: always play TDM under admin, or edit permissions to make everything accessible to user (and in most cases you don't know exactly where is the problem, so you have to modify the whole directory).

I'm pretty sure it was monitor gamma settings (through WinAPI). The sliders in the main menu still work this way on SVN. Which is why I suggested expanding postprocessing in such a way that it would look exactly as OS tables do, so that we could finally drop them. I don't like the current postprocessing, since it is a huge black box with too many variables affecting the output. It also has a controversial bloom which many people dislike, and it does so many render passes that I won't be surprised if it really affects performance (it is great if these passes are disabled when bloom is off). But we should not drop it simply because we did not implement it... hence the idea of two presets: simple one (only gamma + brightness) and "HDR-lite" one with all the whistles.

This is a bug. They should work as usual. Perhaps you should write in Tech Support subforums. Bloom is considered one of the HDR effects. I regularly say that having HDR necessarily means having increased precision of the framebuffer (like 16 bits, of 12 bits instead of 8 bits). TDM does not have HDR. That's why any implementation of bloom effect is a tricky balance between blurring light sources and bleaching bright parts of the screen. There is no way around it. Luckily, you can turn bloom off separately from the rest of postprocessing (?)

From my experience, permissions in Windows are a pain for an ordinary one-guy-one-pc case. The workflow I find plausible is to never switch accounts and never run programs under admin (unless it is some type of system maintenance program). Because if you start switching, you will sooner or later have to edit directory permissions ?

This error is reported when TDM cannot open specified file for writing. Which usually means that it doesn't have rights/permissions to write to the location. So I second Freyk's suggestion about permissions.

In my opinion that's the best solution for now. Ehm... 12 maps by January 2019: ac2\ac2.pk4 -> maps/ac2.map: 2 antr\antr.pk4 -> maps/antr.map: 1 briarwood\briarwood.pk4 -> maps/briarwoodcathedral.map: 2 closemouthed_shadows\closemouthed_shadows.pk4 -> maps/closemouthed_shadows.map: 1 deceptiveshadowsv1_2\deceptiveshadowsv1_2.pk4 -> maps/deceptiveshadows.map: 2 nhat3\nhat3.pk4 -> maps/anoott.map: 1 nhat3\nhat3.pk4 -> maps/forest.map: 1 siegeshop\siegeshop.pk4 -> maps/siegeshop.map: 2 somewhere1_1\somewhere1_1.pk4 -> maps/somewhere.map: 11 springcleaning\springcleaning.pk4 -> maps/sc.map: 1 storm\storm.pk4 -> maps/storm.map: 2 transaction\transaction.pk4 -> maps/transaction.map: 2

BTW, added issue 5072 for this.

There are many options what to do. Reduce light radius of all thunders from 999999 to 99999. It would pass the tolerance then, but would still be 10x larger than size of normal level according to ID software. Reduce tolerance on determinant. But to be honest, it is already very low (1e-16), so matrix inversion will more likely return garbage for almost-singular matrix than report error for properly invertible one. Implement special case --- inversion of diagonal matrix. In such case, no tolerances are necessary. Of course, if someone adds rotation to such a gigantic light, it will stop working.

I have just switched TDM to 1.19.1. Now we have one more version of OpenAL to try in case of problems. Maybe at least one of four versions would work perfectly for everyone

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