Jump to content

stgatilov

Active Developer
  • Posts

    5642
  • Joined

  • Last visited

  • Days Won

    151

Everything posted by stgatilov

  1. Anyone else with the same problem, I wonder? Which exact version of TDM do you use? 2.10 release or some dev build? If dev build then which one and when did the problem start? Could you also post condump? It sounds as if ambient shader does not compile with SSAO, in which case you console should contain compile errors.
  2. Well, the engine is not very accurate regarding first frames of anything, given that it has SMP and other things. I'd suggest trying to disable com_smp, maybe the issue will go away. When SMP is on, we render previous frame while we model gameplay for the next one. It might be a texture rendered specifically for X-ray, or some frontend data which is gathered for X-ray, etc. In order to find the issue, I'd recommend using apitrace to capture OpenGL replay (on a smaller map). It is not nice to use, but unlike RenderDoc, it captures every frame, so you can later find the glitchy one and see what's wrong in OpenGL calls. After you understand what causes this issue, a proper fix would probably be adding some kind of delay to X-ray visualization, or some kind of clear when X-ray is disabled/enabled.
  3. Yes, I guess the manual download does not report that downloaded files are different from the ones website distributes. You can try to copy the TDM directory and run tdm_installer in it. It will check you local copy and only download/repack what's different. If it finishes successfully, then you can be sure you have the correct TDM 2.10 there (at least at that point).
  4. Hey, don't muddle the water more than necessary TDM still perfectly supports 64-bit Windows 7, but it has dropped support for Windows XP. It is surely possible to run old version of TDM under Windows XP, or maybe even backport the recent version. It is possible to run on 32-bit Windows too. But what surely won't work is running TDM inside a virtual machine Except for VMWare. It is yet possible to run TDM inside VMWare guest, but you won't get any pleasure from playing this way. And GPU passthrough should indeed work, but that's a very advanced (and I guess Linux-only) setup.
  5. The error says that after it has downloaded the file, its contents are different from expected. I have just tested clean installation of 2.10 with this mirror chosen (taaaki2). I cannot reproduce the problem. It means that the problem is most likely on your side. It can be: some rights/access problems in filesystem (try to create a different directory, make sure you can write to it yourself) virus or antivirus breaking data (disable antivirus, or run independent virus scans) hardware problems in disk or memory (run some good hard drive and RAM tests --- we already had one user who detected RAM issue after tdm_installer errors) software problem, like broken OS files, drivers, filesystem, etc (run sfc scan, chkdsk, etc.) your network broken either by bad adapter, cable, or by your internet provider
  6. Scripting changes are only applied if you reload game, I can hardly call it "in real time" Anyway, I recommend: Get source code from SVN trunk. Get TDM installation (assets) of the latest dev build with tdm_installer. Read COMPILING.txt, align two directories as described there, build game. When you build engine from source code, it would copy/overwrite TheDarkModx64.exe and glprogs directory to ../darkmod. Yes, you can run and debug the game straight from Visual Studio, the solution is configured accordingly. If for some reason you want to keep clean 2.10 installation or dev build, just copy the whole TDM installation directory: you'll have less confusion this way. It is possible to have single installation but juggle around with executable and glprogs, but I wouldn't recommend that. Just like Doom 3 engine, TDM considers everything in .pk4 archives (they are actually ZIP archives) as a virtual filesystem. So if you take some pk4 file in TDM installation directory and unpack it to the same directory, the game won't notice it and wll work exactly as before. If you want e.g. to edit game scripts, find the pk4 archive which contains them, then unpack its contents and delete it. Then you can easily edit the scripts.
  7. dev16617-10107 is available! I fear this might become the most breaking dev build of 2.11...
  8. Historically, there were several inefficiences in the way stencil shadows were combined with antialiasing. The first improvement landed in 2.10, and fixed most of the slowdown (not even tracked, I suppose). The second improvement landed in the just released dev16617-10107 (5851), and further reduced bandwidth. Now turning antialiasing on increases stencil bandwidth by constant multiplier. So regardless of scene, the different between antialiasing Off and 2x and between 2x and 4x should be more or less the same. Another improvement is about soft stencil shadows (6076), also landed in dev16617-10107. It can be turned on and off by cvar r_softShadowsMipmaps (turned on by default). Unfortunately, this cvar can improve performance, but sometimes it can worsen it too. It would be great if players could test it in various scenes and various hardware and report their results. Here are the gory details about the new optimization:
  9. The latest dev build (dev16617-10107) contains major changes to shaders, which means that the visual look has changed. The goal of the changes is to remove inconsistency between ambient and interaction, and make TDM lighting math closer to standard Phong (or Blinn-Phong) model which is so familiar to everyone. 1) Now specular term in ambient shader is modulated by specularColor instead of diffuseColor. The same problem was in interaction shader, and it was fixed back in 2.08 (5044), now the same change is applied to ambient shader for consistency. 2) Specular term in ambient shader is no longer modulated by diffuse texture. Previously it was additionally modulated by diffuse texture, as if you baked all diffuse textures into specular textures... but only for ambient. In interaction shader, specular term did not depend on diffuse texture (almost --- read below). 3) Directional part of diffuse term in ambient shader is no longer modulated by "(1,1,1) - specular texture color". This was again some kind of hack against the standard Phong model, not present in interaction shader. 4) Removed dependency of specular term on diffuse texture contents in interaction shader. Previously there was additional modulation by (75% + 25% * diffuse texture color). On one hand, it was not changing much because 75% of intensity still goes unmodulated. On the other hand, this is again some rather arbitrary hack on top of Phong model. Overally, I'd say specular has become a bit stronger now. The main trouble with these changes is of course that they can devastate your carefully tuned assets. So please report here your experience with the new version. P.S. The changes were tracked as 5828.
  10. Perhaps better enable automatic saving of crashdumps for this particular executable?
  11. I watched this video and it looks great to me. What exactly you don't like in how TDM behaves in this scenario? I think the current engine has very bad transitivity issues. Like you remove a table, but some things on the table don't drop. Of when elevator goes up, some things stacked on top of each other don't behave as expected. And etc.
  12. Hey, we require OpenGL 3.3 today! And I know only one VM which can deliver that version with hardware acceleration, and that's not Windows XP mode
  13. I think I have some sessions with bad performance too lately. Not sure what it depends on... I thought it could be some multi-monitor/GPU setup, causing framebuffer to go through various layers.
  14. You can download binaries and they'll probably run. Then you can download source code, and follow instructions in COMPILING.txt. If it won't build due to third-party libs, then read ThirdParty/readme.md thoroughly. Rebuilding dependencies is not very reliable though.
  15. The implementation of volumetric lights in 2.10 uses dithering to reduce performance impact. What you show here is exactly the dithering effect: the image looks good in large scale, but on small scale it is a mess of pixels. Moreover, the more high-frequency details you have, the more apparent the dithering artefacts become. So there are only 2 explanations why scene looks better with stencil shadows: Because when you use stencil, volumetric light is disabled --- that's default behavior of volumetric lights in 2.10. Because when you use stencil, volumetric light is used without shadows. This makes dithering artefacts hardly noticeable, since the light itself is very low-frequency, while shadows are high-frequency. With new dev builds, you'll have dithering artefacts as you see in 2.10 with shadows maps, but now you'll see them regardless of your choice. And the reason for that is that now volumetric lights always take shadows into account if mapper wanted them to exist. We plan to add blur and thus remove dithering artefacts: 5850
  16. @Obsttorte, I recommend searching for "ko_angle_horiz" spawnarg and bumping it at least to 180 degrees to improve situation with helmeted guards. I don't think you need to touch alerted counterpart. Also, there is tdm_melee_debug cvar, under which I added some debug visualization. With your changes, it is a bit messed up, but still usable.
  17. Here is one example. To be honest, it is confusing that whether KO is successful or not changes while guard slightly moves around due totally idle animation. But I think I waited for long enough in this case...
  18. I tried the latest trunk and saw the blackjack animation. I'm not sure what the animation itself intends to solve? I see cases where hand is not raised but hit causes KO. Aside from that, the target often moves, in which case this animation lags too much behind. And it feels like a visual noise in general, because the hand goes up and down all the time. As far as I remember, I detected only two problems with KO: Ceiling or doorway blocks it: very annoying for everyone. Helmeted guards are hard to KO, meaning that some hits fail pretty randomly. There are some standard rules about when and how someone can be KOed. I suppose it's something like: Civilian: in any state from any direction Guard: from any direction (maybe only from behind when alerted) Helmet guard: only when not alerted and only from behind Helmet + face grill: no way to KO I recall I suggested removing the additional difficulty in KOing helmeted guards. Because adding such unpredictable difficulty in this case only makes player's life more annoying: if he wants to KO helmeted guard, he'll do it anyway, but after a series of reloads.
  19. Committed the rename in svn rev 10080.
  20. Regarding packaging. The easiest way is to take some existing build, then use zipsync patch to overwrite some of its files. Before that, you need to do zipsync normalize + zipsync analyze to create a small package from the files you want to overwrite. Regarding server. Yes, you need to make it available on any HTTP server. The HTTPS protocol requires an additional TLS library to make it work, and tdm_installer does not include one currently. To be honest, I don't understand what's the benefit of forcing HTTPS for statically hosting a bunch of files. HTTP 1.1 from 10 years ago works perfectly well today, while in HTTPS they release new version of TLS every so often, then declare the old one as insecure, then block all software from working with it, breaking tons of websites. Maybe I should just add TLS to tdm_installer and allow https:// kind of URLs. Although it can cause even more confusion because people will write https:// instead of http:// and be surprised that it does not work. Regarding installing it. Yes, the user needs to go to "Custom Version" screen, paste the URL of your build and select which stock TDM version it was based on. That's because stock versions have yet another manifest which describes all dependencies between them, but your custom version does not. Regarding shaders. I have been changing shaders extensively, including some changes after the most recent dev build. You need to combine engine with the shaders of the same version. So if you build executable from latest SVN but use glprogs from dev build, then they won't work together. You need to copy glprogs directory from you darkmod_src repo to your zipsync patch, so that your package includes them as replacement. That is rarely a problem today, but now is a particularly unlucky moment.
  21. dev16599-10071 is released. See second post for changelog.
  22. Yes, all those missions have incorrect GUIs, including Saint Lucia and New Job. The original GUI engine did not report any kind of error, just tried to continue doing something. And it had some bugs. The latest GUI engine reports almost all issues as warnings, has most bugs fixed, and still tries to continue despite errors.
  23. There are more changes in dev16599-10071, please read the original post. Basically: vector component indexing is fixed expression evaluation order fixed don't disable auto-updates of register because of a reference to it Set command can now have expressions on right side I wonder if we have information about GUI scripts anywhere that should be updated?
  24. We did some refactoring related to shadow modes, and as the result we can now easily switch between stencil and shadow maps on per-light basis. Starting from dev16599-10071, volumetric lights display properly with stencil shadows mode selected in settings menu. It works by forcing the particular lights with volumetrics into using shadow maps instead of stencil shadows. The special "volumetric_noshadows -1" setting is useless now, as well as the whole volumetric_noshadows spawnarg.
  25. You are not alone with this problem. I have added this thread to https://bugs.thedarkmod.com/view.php?id=4109#c14687 Yes, we'd like to fix it. But I'm afraid it won't happen soon.
×
×
  • Create New...