stgatilov

Ok, here is one hypothesis (ping @cabalistic). Our bloom implementation does not disable blending. In only sets blending function to (dst * 1 + src * 0). It looks like src * 0 is always zero and this equation is equivalent to disabled blending. Except that in 64-bit mode we have floating point values in framebuffers, and floating points numbers have special values like inf-s and nan-s, which don't become zero if you multiply them by zero. This effect disappears if we clear framebuffer every time before rendering into it, since any special value will disappear the next frame. However, I see that upsampling FBOs are not cleared (see BloomStage::Upsample) unlike the others. So I suppose that a special float value is born somewhere in upsampling framebuffer and it sticks there forever because we don't clear this buffer and blend new frames onto the old image. Getting special value in rendering is not nice, but I think we will won't be able to get rid of them completely. However, if these values stick forever, then that's a big problem So I guess I'd not try to find where the first special value comes from, and just fix bloom code. In order to check if this hypothesis is true, I need a help from someone who can 99% reliably reproduce the problem (I can't reproduce it on my GTX1050ti). And if this person can compile TDM, it would be even better I think about adding "qglClear(GL_COLOR_BUFFER_BIT);" just before "RB_DrawFullScreenTri();" in BloomStage::Upsample.

Now @AluminumHaste has the same problem: Get weird screen corruption with it on in Flakebridge Monastery.

The fun of permadeath is about getting enough skill in analyzing the current situation and understanding when you can continue and when you should run away. "Run or shoot", as Left4Dead worded it. In ADOM, you cannot win the game without having to run away at least a few times. Having versatile escape options is very important in order to survive in the long run. You can later revisit the problematic section after you cleaned out other dungeons, having more experience and better equipment. TDM has no level-ups and rarely have any items which significantly improve you chances, so this system does not apply: either you skip the problematic section, or you just have to try again and again and quickload when you fail. In Spelunky, you get more resources by investigating more of the levels, but after some time you notice that the more you explore, the more likely you die. To optimize your chances to win, you should ignore some parts and grab only the loot you see nearby or you know about. Once again: estimating the risk is very important, and you have alternatives (often bomb through walls) if something looks too dangerous. I also played Diablo 2 in Hardcore mode, and once again knowing when to run and when to just end the current game session and start a new one was crucial to surviving. The first two games are roguelikes, meaning that most of the game is randomized (Diablo is randomized too). If you die, you play different levels. TDM is not randomized, so replaying is not so fun. I did not play Metal Gear Solid, but as far as I see from a video, it has an option to do open firefight without much pain if you fail stealth, like in Dishonored. I did not play Dark Souls but isn't it just a masochistic game? Not something to compare TDM to.

Maybe, but that needs more work, not worth it for a single-time migration. It is much easier to break tdm_update completely, so that people have to go out and look around to see what happens. This is also good for breaking people's habits. When one sees that tdm_update stopped working and downloads tdm_installer manually, he understands that this is a totally new thing which works differently. And if updater is replaced transparently, then user mentally projects tdm_update habits onto tdm_installer.

For me, save restriction does not work in hardcore stealth games because there is no alternative. If I fail this knockout or get accidentally caught here, then I have options: quickload die and replay a whole section from scratch run away and wait for a long time, after which have much more problems during the whole rest of the mission because every guard is prepared for combat (and killing people is annoying and often forbidden) That's boring! The options 2 and 3 are absolutely opposite to having fun! What is even worse, if I start to care about risk, then I have to restrain myself from exploration. I should not go to some places because I find them too risky! Doing so is absolutely stupid in a game like thief/TDM, where exploration is the core aspect of the game. I never understood what's the pleasure of playing TDM/Thief in ironman mode, even though I tried to do that on a small mission. On the other hand, I won Dishonored 2 in ironman mode without dying/loading and had a lot of fun with it. And the reason why it was fun is that I knew I had a lot of alternatives when I messed up. Like sleeping darts, stun weapons, and unarmed combat. And most importantly, I could pull out my pistol and shoot out through the crowd if things went really bad! As the result, the cases where I failed stealth were the best moments in the whole playthrough, even though I was mostly stealthy and non-lethal. No-killing is a tradition for TDM, we cannot go against it, partly because AI is tuned to calm behavior more than to combat. Turning the player into fighting beast (like in Dishonored) is not an option either. Hence there is no way to restrict save/load without breaking the fun completely for most players. And speaking about cheats in general, there are many reasons to have them. The most important is young players (although this probably does not apply to TDM) and players lacking skill. My dad was a geek. He brought PC to our house when I was six, and showed be QBasic. He also showed me how to use Hex Editor to change gold/time in savegames before anything like Artmoney existed (that was DOS times, so I converted between hex and decimal on paper). I remember how I lifted time restrictions from games, like Prince of Persia and King's Bounty. That's the only way I could play through those games at that age. Of course, much later I revisited them and won them without cheating. I played ADOM for a long time with backing up my savefiles, effectively removing the permadeath restriction of roguelike genre. The fun thing: it did not help me to win the game After spoiling myself with reading a lot of wiki, I managed to win the game and then started to play it without backups. On the other hand, I'm opposed to having such customizations anywhere in the menu. Having more options usually means that things break more often, and also it hinders players away from the experience prepared by the mapper.

Core game changes won't happen until 2.11 anyway, so mod definitely has its place. But I'd be happy to include save cheat in the core game. Maybe also a command to get/add specified of gold. I don't like the other stuff: all that hacking with objectives system...

You can only get version 2.09 using tdm_update. I had a plan to show warning to players still using tdm_update, but this plan failed because I did not manage to force it to self-update. There is new tdm_update which shows warning, but players can't get it We will delete some stuff on the server when 2.10 is released, so tdm_update will stop working completely. I think confusion should go away soon after that.

Do you mean it can break a mission because it does not consider what would happen if someone dies? Logically, removing no-kill, no-knockout, not-seen restrictions can indeed break a mission. But minimal loot and save restrictions don't change gameplay at all. UPDATE: Wouldn't it be better to integrate a console command into the core game? We already have cheats like: god mode, get all loot, show keys, successfully finish mission. I think it would be OK to have other cheats there too.

I can reproduce the problem. The menu starts in English even though language is French.

What about other settings? Do they save?

Sounds like this issue: 5286 Not sure why guard alert does not count. Maybe getting alerted from another person does not count "by design"?

In general, changing the rules of the contest at the end of it is a very bad thing to do. The rules should be fixed after the competition starts. If anyone cares about the results, changing the rules now will be bad for him, since he tried to improve on a different goal function. And people probably won't confess that they care if you ask them If no one cares, then changing the rules is simply pointless you can as well have no rules at all, and then invent various criteria and rank the missions based on them.

Or rabies

Do you have any problem with light/small objects? I can see the problem with a box, although it happens on "tdm_drag_new 0" too.

I have no idea if this is fixable, since TDM does not make any difference between the two modes. "Borderless" fullscreen only makes the TDM window 1 pixel wider in vertical direction, which supposedly forces most drivers to not do anything fancy but go through regular windows compositing. Also the two modes differ in how they work if you set non-native resolution: proper fullscreen will ask your OS to change resolution globally, while borderless does not support this case at all (not sure what would happen). You can try to play with "Uncap FPS" and "V-Sync", I'm sure some of these settings will remove FPS oscilations.

I wrote to the mirror owner. Meanwhile, I think you can choose mirror manually (not Kowmad's) to avoid the issue.

beta210-05 is available. This one includes 32-bit executables. If you can run them without much trouble and play moderate-sized levels, please give them a try.

That's one reason why there is no menu setting for this On default settings, volumetric lights should not cause much more trouble if you can play with shadow maps well (especially if you can play with maxed soft shadows quality). But in some cases (especially with sharp shadows) the effect might look "noisy" due to dithering. We hope to fix it for 2.11 without harming performance.

I'm sorry, but we decided to not release it yet... Using it will generate a warning. We have bumped into an issue that fog boundary becomes pretty apparent when you are close to it and look along it. Since I guess this is one of the major issues with the old fog, I think releasing something new with the same problem won't be very helpful. Note that unlike the old fog, the new "volumetric" fog makes the boundary plane apparent because that's how it should be, i.e. this effect is an correct modelling of a box-shaped fog with constant density. That's what makes it hard to avoid (I don't even say "fix", because it is not a "bug").

I think we have fixed it on SVN, but not yet released as beta. I have said several times that downloading all FMs is good only for stressing our mirrors. I'm sure you will not even start most of these missions before you have to download them all again for some reason. This button should not exist Speaking of the crash, we can try the "fun" of crash dumps on Linux... The reference wiki page contains no useful information. I don't think anyone (except for the author) will ever run command line profiler and get any useful information out of it. I thought about writing a wiki article about Tracy profiler with TDM, and main parts (like GPU, backend, frontend, game modeling, various cvars/options affecting them, bottleneck, etc.), but have not done it yet. I profile with frontend acceleration most of the time, and Tracy shows stuff properly. Here is one such example.

It means that most likely you can use this "volumetric fog" in the next 2.10 beta. Unless we decide to block this feature entirely. It is quite late in the beta phase to add any features.

I will not put OpenAL recipe from trunk into 2.09 branch and tag. They differ by two minor versions. OpenAL 1.19.1 was in pure C, and OpenAL 1.21.1 is implemented in C++ and was refactored like hell. 2.09b was built with version 1.19.1, and overwriting it with version so different would be a big lie. Perhaps one can release 2.09c just to update OpenAL to new version, I don't think 1.19.1 was so bad that i made TDM unplayable for many people. Moreover, 2.10 is already in beta, and it is counterproductive to waste effort on 2.09 now.

The coefficient was tweaked for "outdoors light getting into dark room" situation. I don't think the location in your video would have any noticeable volumetrics in the real life, no wonder that default setting is too strong for it. The image is heavily dithered, I suppose compressors have problems with it.

I applied all these changes in svn rev 9804. The alpha equation is a bit different (5.0 coeff under exponent), also added a hack to force opaque fog. On top of that, I applied a bit of dithering to reduce color banding.

This word makes me laugh