stgatilov

No, this fix was not applied. The immediate change of EFX parameters can be quite noticeable. I think it can be smoothened somehow, but probably it is better to rethink the whole EFX algorithm. The current implementation (just apply predefined effect of the location we are in) is too basic. Not surprising, given that EAX was included into Doom 3 solely to please Creative.

Thank you very much for your note! I have looked into dhewm3 sources, and it still uses the same linear formula as TDM: https://github.com/dhewm/dhewm3/blob/master/neo/sound/snd_efxfile.cpp#L203 To be honest, I do not understand the difference well. Since AL_EAXREVERB_DENSITY value seems to be in range [0, 1], the two formulas are approximately the same up to a bias of 0.5: the current linear formula has most changes in range [1..2], while the cubic formula has the same change in range [0.5, 1.5]. Of course, the effects tuned for EAX will sound differently on EFX as the result. But we have no builtin presets for EFX, I believe. And there are only a few missions with EFX settings. In Patently Dangerous, this parameter is set to 1 everywhere. In Volta, it is mostly 1.0, and sometimes 1.8 or 8.0. Clearly, 8.0 is wildly off range with both formulas.

Well, I have found and fixed the reason why this file always triggered a repack (4780). It was a stupid case sensitivity issue. However, it bothers me much more that engine repacking does not work for several people. According to console logs, the whole repacking process works perfectly, something fails along these two lines: //replace the old pk4 file remove(srcZipfile); SAFECALL(rename(tempZipfile, srcZipfile), "Cannot rename %s to %s", tempZipfile, srcZipfile); I can only think of two possible reasons: TDM does not have permissions to change/delete the existing pk4 file (e.g. if you run tdm_update under administrator but run TDM as user). The old pk4 file is still open by something when we try to delete it. And since the file is closed immediately before this line and closing does not fail, it should be some other program. The new pk4 file is still open by something when we try to rename it. And once again: since we close it beforehand. it may be some external program (maybe antivirus scans this file since it was just created?). UPDATE: Bikerdude and AluminiumHaste: When the problem happens and you exit TDM, which of the two files are present and which are missing? Do you have XXX.pk4.tmp file present but XXX.pk4 file missing? Do you have any sort of antivirus with something like "active protection"? P.S. For those suffering from the problem. If you look into console and see "Repacking XXX.pk4 ..." message immediately followed by "WARNING:Cannot rename XXX.pk4.tmp to XXX.pk4" without any messages between them, then you can simply do the file rename yourself. Just rename XXX.pk4.tmp to XXX.pk4 manually and run the game.

I start feeling bad about it... Please, if anyone else has missing sounds, immediately copy your tdm_sound_sfx02.pk4 file somewhere (and tdm_sound_sfx02.pk4.tmp, if it exists nearby). Then share these files with us.

Just wanted to add that the latest 2.06 beta also contains noticeable improvements to soft shadows: 15171 Soft stencil shadows: fixed the bug in converting vectors from world space into screen space.15172 Soft stencil shadows: removed old code path (SOFT_SHADOWS_USE_SIMPLE_SPOT)15173 Soft stencil shadows: added anti-halo patch. Most importantly, you should no longer see light or dark "halos" around objects with soft shadows. If you still participate in beta testing, it would be helpful if you enable soft shadows after update and pay a bit of attention to them.If you have Linux OS, it would be great if you at least start some mission with soft shadows and check that you actually see them. The same probably applies to owners of AMD and Intel video cards (or non-standard drivers).

I merged [15171-15173] from trunk into release2.06 branch and committed the merge in 15190. You'd better do this merge again (there will be no conflicts this time) in order to record the merge in the mergeinfo prop of the root directory.

Unfortunately, I cannot agree with you. There are still user-packed pk4. But the pk4 bug is reproducible everywhere, so it will be fixed..

Please report this issue to bugtracker. Be sure to include there a back link to your initial post in this thread. This issue is not urgent, so most likely it will be fixed in 2.07. I think tdm_sound_sfx02.pk4 has some issues with zip compression. When you run TDM, it repacks the pk4 file: so that all ogg files are not compressed. By intent, this should not cause any problems, because tdm_package now follows exactly the same compression rules. That's why you are expected to receive a pk4 file already packed as intended, so that the game won't change it. In fact, this idea works perfectly for many other pk4 files which contain ogg or roq files, but for some reason tdm_sound_sfx02.pk4 is different.

Happens with enhanced ambient and with "r_useGLSL 1" only. This is clearly the behavior of the new ambientInteraction.fs. I did not manage to find where this shader was ported from. BTW, this does not look like gamma correction: color.rgb *= 1 + u_gamma*(1 - dot(color.rgb, vec3(1./3))); P.S. Anyway, report this bug to issue tracker.

Soft shadows without FBO are hacky/buggy. Try to enable "r_useFBO 1", most likely it will help.

Did you try disabling GLSL shaders? Try to set r_useGLSL to 0, then old ARB shaders will be used. If this does not fix the issue with fog, you can also try to toggle various settings like "enhanced interaction" and "enhanced ambient". If any of this changes fog behavior in 2.06 back to its old way, please report exactly what you did. P.S. Make sure that you set r_useGLSL back to 1 when you finish testing!

This is the main source of problems with Linux version: there is no programmer who lives on Linux daily. People who never run native Linux cannot change things like glx-specific antialiasing.

I have just finished the game, and I must say that the graphics feel wrong to me sometimes. I know that it is very good, there is indirect lighting and all those cool stuff... but still it does not look solid. The game by default renders everything at low resolution, then upscales to your native resolution --- so everything looks pixelated. With upscaling disabled, high settings become unplayable on GeForce 1050ti. And on medium setting, you often see something likes this: I guess this is why people are against shadow maps. You cannot get them right in 100% of the cases, and whenever you get them wrong, they look like a fake.

I have Windows 10 Home. And a lot of people here use Windows 7. So I guess Docker for Windows is mostly unusable now (and will continue to be). And Docker Toolbox is simply VirtualBox + other stuff. I hope it would at least run the image without any issues.

I have tried to run your docker image on a fresh Ubuntu 16.04 inside VirtualBox. Installing Docker is relatively easy, although not as easy as 'sudo apt-get install docker'. The docker image for Darkmod build was pulled from the hub, it has compressed size about 200 MB. It has successfully built 64-bit TDM in single-threaded mode. Running with "-j6" failed (something like cc1plus crash), maybe it is caused by VirtualBox. I tried to run the resulting TDM executable outside of Docker, and failed with the following error: ./thedarkmod.x64: error while loading shared libraries: libopenal.so.1: cannot open shared object file: No such file or directoryI had to install libopenal1 to fix it. Then it runs successfully. I think this library is needed by TDM itself: if you download TDM via tdm_update, it will most likely print the same error on a fresh Ubuntu. I have updated the compilation instruction for 2.06. You can see the expected contents of COMPILING.txt in 2.06 here. As you see, for Ubuntu distribution you only have to: sudo apt-get install scons m4 subversion mesa-common-dev libxxf86vm-dev libopenal-dev libxext-devAfter that you can build TDM directly using scons command line. So the Docker won't simplify life for contributors with Ubuntu 16.04.On the other hand, a different version of Ubuntu may need additional steps.Different distribution may require some nontrivial changes, as seen in the current instruction for Debian on the wiki.It seems that having one Ubuntu-based Docker image would help users of Debian, CentOS and Fedora to build TDM.Also, having a single Docker image should greatly reduce a problem when Linux build is deeply broken, and you cannot even understand which errors are due to wrongly configured environment, and which happen because of the code changes. One thing I am interested in is how easy it would be to run this Linux container in Docker for Windows.If is it significantly easier than installing Ubuntu in VirtualBox, then Docker image can be helpful for Windows-only developers.It can be used to check for build errors, although it won't not allow to run the resulting executable.

So docker is just a Virtual Machine (you may call it lightweight, but I think in general case it can get as heavy as a full VM). Anyone can create a docker image and put it somewhere, it can exist as an unofficial thing (like the unofficial installer), or be added to the assets SVN --- it does not matter. I think it should not be made official, because I'm afraid no one would maintain it, and it would soon become a yet another "obsolete way to build TDM on Linux". One of the reasons why Linux build instructions are so bad is that currently every active developer uses Windows as main OS We usually use VirtualBox VM on Windows to build and run Linux version of TDM. This approach perfectly works for building TDM, and barely works for running it.VirtualBox uses a discontinued project for OpenGL support in Linux guest. It is enough to at least run the game in TDM. But I'm afraid it will die at some moment due to graphics modernization.I'm pretty sure that Docker won't solve the OpenGL problem better than VirtualBox does. Now the question is: how is Docker better than VirtualBox?Running Linux containers on Windows is possible, but it seems to work via virtualization too (some Windows version of Docker even uses VirtualBox, I believe).Why not simply create a VirtualBox Linux VM and distribute its VHD to everyone?This VHD can be used to build TDM on Linux, either manually or automatically. It cannot be used to play the game, but Docker won't help with it too. So I'm trying to understand who would benefit from having a Docker image.The players surely won't: they download binaries and run them, they don't need to build TDM, and even if they do build, playing the game is much more important for them.The developers need to build and also run the game (even if it is hardly playable). I'm afraid running TDM in Docker will stop on "OpenGL not initialized" error. Is it possible to build binary inside Docker and than to run it outside Docker on arbitrary Linux environment?Also, developers need to debug the game. I have used the crazy ddd tool twice to fix crashes. Someone else will use another tool. Will developer be able to add such a tool to prebuilt Docker image? I believe that immutability is not a benefit but a burden for an ordinary developer.So perhaps administrators can benefit from Docker. We can run autobuilds in the Docker environment. But they can be run in a native Linux as well. Yes, Docker can make it easier and more reproducible, I suppose. The build environments are different, and TDM can build on one machine and fail to build on another one. In such case it is better to fix compatibility, so that it builds on both machines. Sticking to Docker means sticking to single Linux environment and stopping to care for the other cases. This is OK for Windows world (e.g.: we support only MSVC2013), but I believe this is not the default way of doing things in the Linux world. Please keep in mind that 1) I am quite a pessimistic person and 2) I don't know Docker Maybe instead of discussing Docker, you can just create an image and share it with other Linux (and non-Linux) guys. If it gains some popularity, it would be much easier to see whether it is a welcome addition or an unnecessary thing. P.S. Added issue for build instructions update.

I was the last one to mess with Linux build. I'll update build instructions for Linux after 2.06 release. As of 2.06 and SVN, you can build Linux version from source code root directory by running: scons BUILD="release" TARGET_ARCH="x64" -j6 ..If you omit BUILD setting, it'll simply build some default configuration (debug, I believe). If you omit TARGET_ARCH, then it'll build 32-bit. If you omit ".." at the end, then you will only get deploy-style binaries in the current directory (without debugging info). If you add "..", then you will also get development-style binaries in "../darkmod/". The ".." argument is the only non-intuitive thing now: scons needs it to be able to write outside of the current directory. I usually use CMake at my work for building C++ projects on Windows. However, adding it to TDM would make build more complicated for Windows coders. And tweaking MSVC-specific parameters would be harder (yes, there are such tweaks). Also, GCC and MSVC builds are different in too many ways, it would be very hard to write a single build process on CMake for both platforms. MSVC is not too bad after all, if you apply most of the changes to props-files instead of vcxproj, and if you have a habit of keeping vcxproj file clean. The directories linux/win32/win64 are somewhat messy now. They could benefit from some cleaning. However, the very idea of keeping all the dependencies in SVN is quite good for Windows platform. The dream of moving from SVN to Git is surely caused by The Grand Github Hype But I think it will never happen to TDM. Assets are simply too large, so they will stay in SVN forever. Having two different version control systems for a single project is a stupid thing to do. Plus: Git is order of magnitude more complicated and less user-friendly than SVN. There are a lot people here who are not programmers at all, and they use TortoiseSVN without much complaints. If you ask them to use Git, you will get into serious trouble The boost thing is no longer needed to build TDM. I hope some day tdm_update will be refactored to not depend on boost, then we can finally remove boost from SVN and be happy. As for the docker thing. I don't understand yet what is the benefit of it. Here is what I see in your docker file: RUN apt update \ && apt upgrade -y \ && dpkg --add-architecture i386 \ && apt update \ && apt install -y build-essential \ m4 \ mesa-common-dev \ python-dev \ libbz2-dev \ scons \ subversion \ libc6-dev-i386 \ g++-multilib \ libx11-dev:i386 \ libxxf86vm-dev:i386 \ libopenal-dev:i386 \ libasound2-dev:i386 \ libxext-dev:i386 \The problem of building and installing 32-bit stuff on 64-bit Linux will be gone after TDM 2.06, because we have 64-bit version now. The other commands in the first 4 lines are just some basic things which everyone should know if they install anything on Linux. The last command says to install a set of packages. I agree that we should maintain the minimal set of required packages somewhere. But Wiki or readme.txt should be enough for it. Is it right that we can create Docker VM with some Linux properly configured to build and run TDM, and then we can deploy this VM both to Linux players and Linux developers, and they can simply run everything from the Docker container on their Linux, even if it is different version/distribution/architecture/whatever? What about native libraries then? For example, will everyone use the same OpenGL or OpenAL library, regardless of the hardware they have? One last note about automatic builds. I really like the idea of doing automatic builds of TDM on all platforms. Also, it would be great to automatically run TDM, start some default mission and check that TDM does not crash =) It would solve some problems we have now, like Linux build being broken for months without anyone to care However, it needs some serious administration efforts.

Most likely you can use tdm_force_savegame_load to load savegame from different revision. If loading a save from different version crashes after this, then two versions have different savegame format. But I do not recall any savegame format changes recently, so maybe it will work.

The VertexCache system of original Doom 3 is a mess. It was noted at least here and here. Do you normally work on GitHub? Probably I need to checkout it and look at some places... From brief glance, it looks exactly as the VertexCache used in BFG code. Which is great! I hope that it would significantly reduce driver overhead on CPU side Isn't the same true for Doom 3 BFG ? It takes about 192MB of video RAM. I hope everyone has at least 256 MB today. Can you provide any numbers, i.e. how much bytes are used currently on a large mission? I thought interaction is just a pair of entity + light pointers + few other data. Are they so costly to generate each frame? Shadow mesh generation can make a difference in theory. But as far as I know, dmap already generates shadow meshes and stores them in .proc file (e.g. noted in this review). What is the supposed additional benefit of static shadow cache generation over the precomputed shadow geometry we have now?

I know that I need to end the curse, it is said in the objective. But I had absolutely no clues about how to do it, no information about why it started and where to search (well, it was said somewhere that everything started with builders/pagans conflict, but it is too generic). As for picking something at the crypts and dropping it somewhere, I have written in point 3 that it was not explained anywhere. Does the player have to guess himself that he has to move that thing into that place? And I still don't understand how to get the thing (point 2) without noclipping. It seems that either something is broken, or I managed to miss some very important part of information, without which the curse-removal objective turns into blind guessing game. UPDATE: And what about "player notes" (point 1), were they removed in updated version of FM?

Just played through this mission on 2.06 beta. Did not finish, unfortunately I have realized why I don't like missions with undeads today. It is because there are too many of undead, and you generally don't have enough weapons to kill them all (although I have found a lot of weapons in this mission, I still doubt that I could kill all the haunts with them). So it becomes increasingly annoying to search for something over the whole map when you have to constantly hide from those dead bastards. Also, you cannot turn on your lantern, because it usually means quick death if some door opens nearby, so you have to search most places in complete dark, which makes your search less reliable and less colourful. As a result, the initial fear of undead in the mission gradually turns into almost complete neglectance of them and save-load scumming. In an ordinary mission, I can at least play in the "knock-them-all" style, which makes additional passes over the map faster and less annoying. I don't like the autoclosing doors. First they really freaked my out, because I thought that someone or something was closing it After I got the idea of autoclosing doors, I still don't like it because it makes it harder to remember where you have been and where you haven't, which is not easy in this mission I entered through the crypts and quickly found enough loot. Then it was rather easy to find the scepter and the book. After that I got stuck completely with the curse removal objective. I have rescanned the whole map, and I did not find any clue about the curse. I have looked through this thread and noclipped through the map, and here is what I don't understand:

Yes, it is definitely missing in the Accountant missions. On the other hand, all or almost all the other missions do not have anything like "secrets". I suppose that there were plenty of discussions about [counting secrets] vs [not counting secrets] in TDM, maybe even starting from before the very first public release Perhaps you should revive some old discussion or create a new one (after 2.06 is released). If there is a way which suits well, then it would turn into feature request

A few graphical issues from 2.06 beta testing 1. The doctor's chair turned absolutely black in 2.06, see issue. 2. The face sculpture on the wall (in Lord Vicker's garden) has some issue with lighting (in 2.05 too): when I come close with lantern on, it is still mostly black. Perhaps normals are wrong.

Ok, now for the 2.06 beta results. 1. I have noticed an issue with mirrors. It is partly reproducible on 2.05 too. 2. Water renders incorrectly with FBO, see issue. 4. Did you use any specific skybox or the default one? In 2.05 I see dark clouds, while in 2.06 beta I see stars, and even the city with windows lit in the distance. This skybox also applies to the place I wrote about in point 3. Maybe I see different results because I used noclipping...

I decided to play this mission on 2.06 beta. I do not play TDM often now. I mostly played missions about six years ago. I have just played through the Accountant missions, and I must say: for the first time I feel like I have played a real Thief game , not just a fan-made mod. I wonder how you do all of this? Do you have a job? a family? Maybe you don't waste time on sleep? Or all the people from "Special Thanks" also worked equally hard on the mission? Most of the missions I played so far have all the bare gameplay necessities in place, but they rarely even have a briefing. But this mission is so well-polished! It seems that no area of the game was discarded: there are cutscenes, lots of voice acting, some special models/animation. There are a lot of interesting stuff to search for, even for a moderate player like me. And this is not even counting secrets, which are also plenty It returns back the joy of playing Thief! I found a lot of things which are somewhat hidden, but which are not devilishly hard to find (especially if you read everything). Going through a large diverse map, trying not to get lost in it, is also something which reminds Thief in a good sense. Some specific points: