Jump to content
The Dark Mod Forums

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. 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
  4. Mmm, the bug I fixed today seemed to have no relation to scissor What's your estimate on vertex color - is it more often per vertex or per draw call? I'd think per draw call as it's usually only used for smooth terrain material switch.
  5. 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?
  6. 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...
  7. 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.
  8. I'm having the same problem (had it for some time now, but, always ignored it). I'll just ignore it for now, as i don't know if one of my installed games or programs requires the C++ redistributable which the one from TDM obviously collides with.
  9. 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.
  10. I suppose for this we need to convert existing materials and generate new dds's for each use of image function I understand this is not trivial but it would be a feel-good thing to do. Not only it would save on VRAM but also on load speed (pk4 decompression and mipmap generation) Moreover, textures can be loaded in parallel via PBO + background CPU thread.
  11. Thank you Let me check if I can come up with a simple fix for this (and understand how quick load fixes it) ... Revision 8402 fixes the New Job for me. Regret I'm still not sure how it's related to changes in 8380 or why quick load fixed it. @nbohr1more, @stgatilov, @cabalistic any idea? @grayman, while this should help with missing light interactions, your original missing particle must be something else (uniform transforms vs ARB shaders?)
  12. Point 1 is still valid today. DXT5 makes normalmaps look more blurry and there are artifacts both for simple flat surfaces and more complex patterns. And the DXT5nm mode looks wrong and is unusable.
  13. Wow, thank you for the kind comments everyone, I'm beyond words! And thanks for the walkthrough video @Cambridge Spy, very nice! I've edited the original post to include some helps and hints for those of you trying to hunt down those elusive secrets. Some of them are tricky, just be glad that my wonderful beta testers reigned me a little on not making those secrets too difficult I'm so glad the storm upstairs was so well received! I spent a fair bit of time very early on in the design getting that thunderstorm put together. It's still in the early phases as far as what to build next. Certainly we'll get some sequels for In Danger of Judgment in which we defeat (or get crushed by!) the dreadful Crushers gang. I've also got a document I wrote up back at the beginning of 2019 with all sorts of missions-in-embryo; that's actually where my ideas for In Danger of Judgment were pulled from, and I'm considering building out another one of those ideas into another 20-30 minute mission, particularly so I can get more practice doing decent outdoor scenes (you'll notice I very purposely avoided outdoors for this first mission ). Also, I've been a little out of the loop with work recently, anyone know if the mission download server is healthy again? If so, I'll have to go off and find the people that can help get this uploaded officially.
  14. 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.
  15. Looked at CoO: Behind Closed Doors. For the loader screen background, 2048x2048 jpg was used; presumably 16:9 horizontally compressed to 1:1 (not 4:3). The title and associated text was burnt in there, but there was still text specified in the .gui file, namely that associated with the Mission Loading bar. The specs still used "0,0,640,480" throughout. I was surprised that .gui file continued to reference a ".tga" file as background, even tho it was now a .jpg (but otherwise the same path and filename) .... whatever works. My screenshots were at 1960x1080, so I chose one at full height and compressed the width to 1080 (i.e., 1:1) as well. Looked much better than before, tho still banding (some from the original screen image) and color shifts in gradients. I can live with that. For lazyness, I overlaid the title and associated text using the .gui method, rather than burn-in. If run on a machine with 4:3 ratio, the strings will not be in optimal locations, but on the other hand, the font characters will be normal size, not squeezed. All good
  16. Here's my playthrough video of In Danger of Judgment:
  17. 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...
  18. Documentation for the Hidden Hands series and this mission added to the wiki.
  19. Great mission. Not too massive, not too small, just right!
  20. Yesterday
  21. this was a delightful little map, thank you so much for it! I got about half the secrets; I couldn't if those are part of the total. Hints, please?
  22. I believe there were two main reasons: 1) Multiple team members complained about compression artifacts in pre-compressed normal maps and opted to not use them. This also had the benefit of faster mission loading. 2) Pre-Compressed Normal maps cannot use image program functions like addnormals and heightmap so they were seen as potential stumbling blocks for material re-use workflows which were the main source of asset variation early in the mod
  23. I can repeat this BUT black is resolved by quick save\load, i.e. it's only black between map start and first load. Also, I can see the quick save/load adds draw calls and tri count. Is this what you see too? If so, it's probably related to BFG-style area\portal culling changes.
  24. Ok, I fixed the problem, I had to uninstall the redistributable package in order for TDM to install the files for the updater to work properly.
  25. Perhaps it's not texture-related, but rather the vertex/index buffers. That might suggest memory corruption or possibly missing/incorrect GPU fences.
  26. One of the worst BSG episodes but with one of the top titles from Bear McCreary. Reminds me of Led Zep (Kashmir) and King Crimson (Vroom!).
  1. Load more activity
  • Newsletter

    Want to keep up to date with all our latest news and information?
    Sign Up
×
×
  • Create New...