Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


stgatilov last won the day on December 6

stgatilov had the most liked content!

Community Reputation

619 Legendary

About stgatilov

  • Rank
    Lead Programmer
  • Birthday 08/26/1989

Contact Methods

  • Website URL
  • Jabber

Profile Information

  • Gender
  • Location
    Novosibirsk, Russia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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).
  3. 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.
  4. 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 (?)
  5. 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
  6. 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.
  7. 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
  8. 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.
  9. 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
  10. Just committed binaries of OpenAL 1.19.1 to the code repo (svn rev 8438). Let's hope it will keep everyone happy.
  11. Speaking short, you should definitely reset this cvar to default and enable antialiasing. You will get much better performance then
  12. 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.
  13. 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...
  14. 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.
  • Create New...