Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by stgatilov

  1. 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
  2. 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.
  3. 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
  4. Just committed binaries of OpenAL 1.19.1 to the code repo (svn rev 8438). Let's hope it will keep everyone happy.
  5. Speaking short, you should definitely reset this cvar to default and enable antialiasing. You will get much better performance then
  6. 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.
  7. 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...
  8. 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.
  9. According to good issue-reporting policy, please, attach your darkmod.cfg and condump when this happens to the issue.
  10. 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.
  11. 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.
  12. 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 ?
  13. 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.
  14. 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...
  15. The wiki should be working again.
  16. 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 ?
  17. 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.
  18. 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.
  19. 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 ?
  20. 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?
  21. 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...
  22. 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.
  23. 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.
  • Create New...