General 2.07 Feedback

[Springheel 4645]

The amount of slowdown depends a lot on the quality settings of the soft shadows as well.

[peter_spy 1603]

Yup, I mentioned that as well. If you have time, you can download a thingie called MSI Afterburner/RivaTuner. It's a bit complex to set up, but you can use it to monitor CPU and GPU use while you change options.

 

That's why I'm not so sure about shadowmaps replacing stencil shadows, at least in the current state of things. If you upgrade your rig / switch to a new-gen CPU, you'll see that stencil shadows work very nicely with it (you should have a lot of overhead here), while shadowmaps switch that load onto GPU, which is already busy with other things. I hope I'm wrong, but I got the impression that we may run into performance problems here as well.

[Spooks 703]

 

By the way. Does this happen in the 2.07 Hotfix beta?

 

I've made some noise about this issue in the dev forums since I consider this to be a core functionality.

 

Sorry for responding late, I only saw this late last night!

 

The problem persists in the hotfix beta. I had a confusing, long and fruitless second bout of testing. My materials are a mess and I have multiple entries with the word "sandstone" in them. So okay, here's a correction.

 

I do not have a custom "overwritte" material defined in my fm/materials folder. Instead I have a custom texture with the same name as the core texture and I assume that it is sufficient to overwrite how the material looks in-game. I assume that it's sufficient because I still remember testing the texture in-game prior to updating to 2.07 and it showing without a problem, but I don't know if I used an intermediary material and/or renaming my texture.

 

Here is the biggest difference, my texture is a .tga and the default is a .dds (and as such, in a different folder). Converting the .tga to a .dds and placing it in the /dds/... folder makes it load fine ingame. Still, reloadImages will overwrite the default .dds to the custom FM .tga one, so what gives? Imo it's still inconsistent behavior.

 

This makes it a non-issue for me since I plan on converting the appropriate diffuse maps into dds files when releasing anyways, but it still feels very weird and I can't shake the feeling that this is NOT how the behavior used to be prior to 2.07.

[peter_spy 1603]

AFAIK, that was always the workflow for .tga and .dds. The latter don't get refreshed with reloadimages, only .tgas do. Not sure how the command works under the hood, but doesn't it just check file creation date/time and update the newer files? That's why .tgas will always get prioritized over dds.

[ChronA 2]

After finally realizing there was a new Dark mod update, I am loving 2.07 so far. This project continues to impress me with its commitment to customization and polish. Once I got all the new options dialed in the game really runs well and looks beautiful.

 

My only minor quibble is that my copy of the game seems to have somehow lost the texture for the compass item during the update. I don't think anyone else has posted about any similar issues so it must just be me. I don't suppose there's an easy way to fix it, short of reinstalling?

[VanishedOne 547]

Possibly http://bugs.thedarkmod.com/view.php?id=4986

Edited April 1, 2019 by VanishedOne

[ChronA 2]

Yep, that's the one. Thanks a bunch.

[wesp5 335]

My only minor quibble is that my copy of the game seems to have somehow lost the texture for the compass item during the update.

I'm glad I'm not the only one! Can you post your system specs so we can see if we have something similar?

[ChronA 2]

Sure. Currently traveling and can't recall all my desktop's specs from memory (only that it has a GTX 970 and an i7), but I'll post as soon as I get back. I'm also curious whether the fix in the bug thread will work. Guess I'll find out in a few days.

[wesp5 335]

I'm also curious whether the fix in the bug thread will work.

Can you point me to that fix, please? Unless you mean the shadows off/on trick that I use myself...

Edited April 2, 2019 by wesp5

[ChronA 2]

Yeah, just the shadow toggle trick.

[ChronA 2]

My system specs: Intel i7-6700 (running at 3.4 GHz of 3.4 GHz), 16.0 GB RAM, nvidia GTX 970 with 4GB video memory.

 

Graphics drives were a few months out of date, but updating them to 419.67 had no effect on the compass... except perversely making it so rather than being almost instant as previously, the soft shadow toggling trick now takes 5-6 seconds to fix the textures.

 

An interesting note, this new delay lets me see that the compass always starts out white, even if I have soft shadows turned off before launching the first mission each game session. So I guess the compass rendering starts out broken no matter what. The lack of soft shadows just triggers it to fix itself each time. Weird.

[AluminumHaste 1067]

And you confirmed that the game is using the GTX970 with something like GPUz?

[zergrush 60]

Yup, I mentioned that as well. If you have time, you can download a thingie called MSI Afterburner/RivaTuner. It's a bit complex to set up, but you can use it to monitor CPU and GPU use while you change options.

 

That's why I'm not so sure about shadowmaps replacing stencil shadows, at least in the current state of things. If you upgrade your rig / switch to a new-gen CPU, you'll see that stencil shadows work very nicely with it (you should have a lot of overhead here), while shadowmaps switch that load onto GPU, which is already busy with other things. I hope I'm wrong, but I got the impression that we may run into performance problems here as well.

 

As of the moment, on my old laptop, stencil shadows cause my CPU to overheat quite badly (while using experimental multicore support), but the game runs very smooth. In opposition, shadow maps make for a choppy framerate but are much more forgiving on the CPU. My question as of the moment is whether future updates will bring any significant improvements to this, especially with the further upgrades to multicore support planned along the line. It's no secret TDM is a resource demanding game due to the amount and detail of light sources and perhaps also due to the complexity of AI routines. I was just wondering what is the ceiling to be expected in the long run, especially for low-end PCs, since I consider support on legacy devices an important factor on the accessibility of most free games.

Edited April 7, 2019 by zergrush

[duzenko 660]

 

My question as of the moment is whether future updates will bring any significant improvements to this

Things are going to be improved, at a cost

[wesp5 335]

And you confirmed that the game is using the GTX970 with something like GPUz?

If this is about the white compass that I see too, I have an i5 3.00 and a NVIDIA 1050 and I'm absolutely sure it is running on the GPU. Also this error was only just introduces by the soft shadows of 2.07, I never had this before...

[ChronA 2]

And you confirmed that the game is using the GTX970 with something like GPUz?

Yes, TDM is definitely using the 970.

[peter_spy 1603]

As of the moment, on my old laptop, stencil shadows cause my CPU to overheat quite badly (while using experimental multicore support), but the game runs very smooth. In opposition, shadow maps make for a choppy framerate but are much more forgiving on the CPU. My question as of the moment is whether future updates will bring any significant improvements to this, especially with the further upgrades to multicore support planned along the line. It's no secret TDM is a resource demanding game due to the amount and detail of light sources and perhaps also due to the complexity of AI routines. I was just wondering what is the ceiling to be expected in the long run, especially for low-end PCs, since I consider support on legacy devices an important factor on the accessibility of most free games.

 

The good thing is, the game does seem to scale with CPU as well. I switched from first-gen i7 to coffee-lake i7 some time ago, and an average "drawcall threshold" in FM rose from ~3000 to ~6000. That's a nice improvement, although we're talking 8 years between CPU mfg. dates, so it's not as impressive as you might think.

 

One thing you might want to know about is that the whole game graphics pipeline is currently very disrupted, so it's hard to measure things properly. Complex multi-stage materials and multi-material models are the main culprits (basically "anything goes", no limits). I'm trying to get back to more "by-the-book" setup with my custom environment, and while things look promising here, it's still far from comprehensive model and material library on my end.

[zergrush 60]

 

The good thing is, the game does seem to scale with CPU as well. I switched from first-gen i7 to coffee-lake i7 some time ago, and an average "drawcall threshold" in FM rose from ~3000 to ~6000. That's a nice improvement, although we're talking 8 years between CPU mfg. dates, so it's not as impressive as you might think.

 

One thing you might want to know about is that the whole game graphics pipeline is currently very disrupted, so it's hard to measure things properly. Complex multi-stage materials and multi-material models are the main culprits (basically "anything goes", no limits). I'm trying to get back to more "by-the-book" setup with my custom environment, and while things look promising here, it's still far from comprehensive model and material library on my end.

 

So does this mean significant gains in performance would only come if most TDM main package textures and materials are remade and guidelines for mappers are imposed on creating custom ones? If so, that sounds like an overwhelming task ahead.

Edited April 8, 2019 by zergrush

[peter_spy 1603]

I don't think replacing all current models makes any sense, but at least newer ones can be optimized better. That will require different approach though, basically not using current texture material base (consolidating materials, making new textures etc.), so it will add to the mod package a bit. It's a difficult situation to get out of, no doubt about it.

[peter_spy 1603]

One thing I noticed lately while writing projection materials for spot lights: in previous versions, if you didn't declare a falloff texture in your material, the engine would default it to lightFalloffImage lights/squarelight1a.tga.Yesterday
I noticed that I have to declare that in my material, otherwise the light acts as if it had lightFalloffImage set to _noFalloff. The projection texture didn't fade further away from the light source.

Edited April 11, 2019 by Judith

[zergrush 60]

I don't think replacing all current models makes any sense, but at least newer ones can be optimized better. That will require different approach though, basically not using current texture material base (consolidating materials, making new textures etc.), so it will add to the mod package a bit. It's a difficult situation to get out of, no doubt about it.

 

This doesn't paint a good picture for older missions though. Even if one were to replace older textures and materials with more efficient versions, it means pretty much every FM would have to be revised.

[peter_spy 1603]

That's why peer review is so important. None of us is a pro, we may go years doing stuff the wrong way without even realizing it. In modeling, texturing, and making materials there are often questions with no easy answers, especially when it comes to surface sounds. On one hand, you should strive for 1 material per model, but often models have different types of surfaces. You have to decide whether it is important to have different sounds for respective model parts. It's especially hard with wood, which has consequences in gameplay (arrows and rope arrows).

 

It would be easier if every mission was "cooked" in a standalone package, as in UE packages. That would make missions less dependent on stock content that could be updated, revised, or even deleted. That would make missions bigger though. IIUC, having a small download package was a priority during production, and that resulted in some casualties along the way.

[VanishedOne 547]

There's a longstanding tracker entry for material maps to let one material support multiple surface types - Q4 and ET:QW implemented that in their versions of the engine - but there doesn't seem to be any current prospect of getting it working.

[Jehauri 6]

I'm also having problems with the compass- namely, it doesn't exist. Even in a level the creator confirmed has a compass in it, even in levels that let you select your equipment at the start. It's not a white texture or anything like others were describing, it just isn't there. Pressing V key does nothing, scrolling through inventory shows nothing.