stgatilov

@duzenko, @nbohr1more, thanks for explanation what this weird "map _scratch2" is about! I was under impression that two mirror surfaces cannot work simultaneously at all. So I assume it still does not work completely with the "map" change? What I don't like about the fix is that it gives false impression that many mirrors could works. And to make it work one "merely" needs to choose a random scratch number which does not collide with anything else... which is obviously not maintainable, i.e. also gives false hope in some cases.

TDM 2.09 requires OpenGL 3.3. I built TDM for Elbrus, so the architecture by itself should not be a problem. But Elbrus compiler supported SSE intrinsics. I have a plan to clean this mess in 4550. Did not get to it yet. The plan was to ensure that all intrinsics are disabled if __SSE__ and __SSE2__ are not defined. It should be enough to make TDM compile on various architectures, as long as they have good GPU support and normal Linux OS. To be honest, the fact that this vim3 uses Android instead of standard Linux will be the critical problem. If it won't work on X windows, then someone will have to rewrite quite a bunch of OS-specific code to make TDM run.

Yeah, and the problem is that if something "works for you" on one scene, it will most likely stop working in some other. The existing code has one major benefit: it has been here for some time, and authors test their maps against it. I recall @duzenko removed/simplified some parts of shader code when he migrated it from ARB to GLSL, but in the end we returned everything back to how things were in 2.05. And in most cases, this return was done because something was found by mappers to be broken during 2.06 beta. By the way, existing shaders already have something called "rim" and "fresnel", most likely added by previous adventurers. But unfortunately people like to write more than read. Not that I understand myself why it works as it works... I'm afraid I'm too fond of mathemathically correct methods.

Aren't all modern GPUs scalar? Unlike old AMD GPUs which actually had vector compute units. If they are scalar, then replacing three operations on floats with one vec3 operation should do nothing performance-wise. Even if the intermediate assembly shows less instructions due to using vector-based ones. On the other hand, it may be that same operation is executed three times (once per component) instead of one. But 1) I don't see much of such computations in tonemap shader, and 2) it should be very easy for shader compiler to eliminate such duplicate computations. Given that shaders have no notion of pointers, no aliasing, and no recursion, the compiler most likely inlines "mapColorComponent" function and does common subexpression elimination. I have no objections to making this function work on vec3 instead of float. Just don't see the point.

The announcement about 2.09 release will come soon. I'd like to thank everyone who took part in this beta phase! With so many people taking part in the beta phase, we can make official releases more stable, and ready to be run on diverse machines that players have! Not to mention: with the diverse set of FMs we have In order to switch from beta build to the official 2.09 release, just run tdm_installer with default settings and allow it do what it wants. You can restore config file at the end of update: it is perfectly safe this time. Please check that tdm_installer displays version 1.02 after self-update (in window title). I have tested and verified it myself, but better check it to be safe. Actually, beta209-06 and release209 are exactly the same versions, so this update will be purely cosmetic: no new data will be downloaded, no savegames will be broken between these two versions.

I wonder if you have the exact same GPU model as @Araneidae? Do you happen to use the same driver? (I.e. same OS, and same type of driver in case you are using Linux)

The installer always downloads the tdm_installer.ini when you leave the first page, unless you check "Skip config file download" (which is necessary mainly for debugging). This might sound inefficient, but config file is a small chunk of text, so it's not a big problem downloading it again and again. The root of error is clear: installer does not download config file. Maybe it also cannot download itself (i.e. cannot self-update). Maybe it also cannot update your TDM installation, and you are still on old version (although I'm pretty sure it would throw some error if that happened). I have no idea why download fails. Perhaps if you share log file immediately after the run when config download failed, it would show something.

No problem. I guess most of our programmers don't do any gamedev on their daily jobs Knowledge of C++ language is more important, I would say. In general, it is not a good idea to span through text and try to optimize everything you don't like. Because most of the code should not be optimized: you will not improve performance in any way, but you can introduce errors, make it less readable, etc. It is better to use profiler to see which parts actually take time, then optimize them. Without profiler you cannot even be sure you make the code snippet faster (at least not slower). It is known that programmers are pretty bad at predicting low-level performance. Yes, compiler knows both arguments are compile-time constants, so it computes this value during compilation. While I have heard from many people that Java compiler can optimize code more aggressively because of high-level nature of the language, my experience shows that C++ compiler is much better at optimizing things. Compiler does not compute any of these values during runtime. It computes them during compilation and inserts final constants directly into the assembly code (as "immediate" values). You should get at least some knowledge about C, I would say. In C/C++, if you divide integer by integer, then no floating point numbers are involved at all. As @nbohr1more says, this whole file is not used in TDM. You can of course play with source if you like, but if you don't see a function in profiler, then all optimization efforts are useless (counter-productive, in fact). I'm not sure you will be able to get noticeable performance improvement this way. I think the toughest parts of our shaders are bound by memory access (e.g. texture fetch in soft shadows, or raw bandwidth in drawing shadow volumes). Due to massively parallel nature of GPU, it means that even if you make all computations 2 times faster, the actual performance won't change at all. At least that's my experience with soft shadows. There are a lot of computations there, but adding more will not worsen performance, because texture fetches are slower anyway. And given that fanatic optimization of computations often make them much harder to read and understand, it sounds counter-productive again...

Objects falling through table in UE4. Is it "bug for bug compatibility" with TDM or UE4 also has problems with serious physics?

Sounds like something which should be fixed, no? Do you see anything suspicious in the log file when it cannot update? Is your user allowed to overwrite the ini file?

This is very strange. Did you take screenshot of the new failed attempts? Perhaps it is some problem on your side after all...

Apparently, the cloud mirror is still unreliable. I'm afraid I'll have to bring it down UPDATE: Disabled my mirror. Try again: it should work now.

Did anyone try 32-bit executables?

I guess I'm the main source of this attitude. Yes, that's mainly because of maintenance burden. TDM has reached the state where compatibility is much more important than development. We cannot say "we have upgraded this feature, but as the result these FMs no longer work, and we decided that breakage is well worth it", that would be betrayal of TDM mappers. But since we want to do some development in future too, we have to constantly think about how to avoid getting locked by backward compatibility. And that's the main reason why I was so pissed off by GUI customizations. Yes, I agree that my initial reaction was too aggressive. There was a set of conventions for mappers, established by the original developers of the menu GUI, which were there in order to provide backwards compatibility without compatibility lock-in. But due to lack of some customization features, the protocol was broken by mappers. I have already spent at least a month working on the new system (because GUI scripts are damn painful), and I will spend even more on it. Then even more on fixing the missions which break the convention (in case authors won't do it). And I know I can't drop this work because otherwise GUI will become more and more locked due to compatibility. Now consider jittered screenshots. Is it an important feature?... well, it is not. I would say TDM can safely live without it: only a few people use/know about it, and most likely rarely use it. And it has absolutely no effect on gameplay. However, we have to fix it because "it was there from the very beginning". My immediate worry in such situation is that trying to fix this unnecessary feature would break something necessary. For instance, there was considerable risk that the fix would break portal sky in some situations (although @nbohr1more's fix is very isolated, and I guess it won't break anything). Doesn't it sound counterproductive trying to fix unimportant feature risking to break something important? Keep in mind that leaving it in the code means that it will most likely be broken again in the future (especially given the pace of graphical changes), and the same dilemma will return again. So the best decision would be to remove the whole feature of jittered screenshots, which I honestly wrote about. Of course, it is the responsibility of TDM team members to fix the existing features, even if they don't want to or don't agree with their existence. But wouldn't everyone be more happy if the time wasted on fixing these minor things would better be spent on something more useful and important?

Another major message is pcm_dmix.c:1075:(snd_pcm_dmix_open) unable to open slave, which is probably the reason by default device cannot be used by ALSA.

Judging from Could not open playback device 'default' message, "default" device for ALSA is not configured properly. I hope someone more familiar with ALSA configuration could explain how to change the default.

Which version of TDM exactly do you use? You can open game console (Ctrl + Alt + Tilde) and post here the 4-digit number written in its botton-right corner. Or post condump. Which OS do you use? I assume you use 64-bit executable. Which FM do you try to boot? Could you check for FM updates in the following way: Uninstall mission. Go to in-game mission downloader and check if this mission is in the list. If it can be downloaded, download it. Now install the mission and try again.

beta209-06 is available. Don't forget to check "Custom Version" on the first page of installer. This beta is "release candidate", meaning that unless something very bad happens, it will become final 2.09 release. It has only a few minor changes compared to the previous version. However, there are several important differences between this beta and the previous ones: The archive with 32-bit executables can be (downloaded from here | not any longer) . It should be unpacked into the installation directory, and includes both Windows and Linux 32-bit builds. It is important that at least someone tests these versions. If you decide to do that --- please write about your experience. In order to test mirrors system with tdm_installer, I have established a second mirror on CDN. Now it used with 80% probability. This should be enough to check if there are any emergent problems with mirrors in tdm_installer. But I must say that I'm not confident in this second mirror, so if you see any errors on the installation screen (during Download, Verify or Repack), please post a screenshot and log. Unfortunately, I could not use the mirrors which were used for TDM delivery previously (long story). The new mirror is rather weird: it is very fast but not 100% reliable. It least I had some problems with it a few years ago which I could not resolve. Now I have changed its configuration and hope that these problems won't return. But I'm not sure.

There will be effect on all programs started with these env. vars. I'm not good in bash, but I think the export-ed env. vars only take effect on all programs started from the shell where you did export, and until you close the shell. Also the only "unexpected effect" would be OpenAL writing log files.

Popup texts in the settings menu is the most wanted feature since something like 2.06 ...

You are not able to do it for quite some time already (on Windows). It is not necessary with FBO-based rendering. Because everything can be rendered at 25% or 50% of your native resolution (you choose), and then stretched over the whole screen.

Hmm... I guess it is confusing text. Perhaps I should hide the top text when installation is over. The config restoration happens immediately. You cannot hit Cancel because you cannot cancel the installation: it has already finished.

The bug should be fixed now. Please try again.

New version of installer is available. Suppressed errors from user file having bad named in TDM installation directory. Disabled buggy free space check on 32-bit Linux.

No comments: #include <experimental/filesystem> #include <stdio.h> namespace stdfsys = std::experimental::filesystem::v1; int main() { stdfsys::space_info stdres; stdres = stdfsys::space(stdfsys::path(".")); printf("free : %0.3g\n", double(stdres.free)); printf("cap : %0.3g\n", double(stdres.capacity)); printf("avail: %0.3g\n", double(stdres.available)); return 0; } user@ubuntu:/mnt/hgfs/thedarkmod$ g++ temp.cpp -std=c++11 -lstdc++fs user@ubuntu:/mnt/hgfs/thedarkmod$ ./a.out free : 4.93e+11 cap : 1.02e+12 avail: 4.93e+11 user@ubuntu:/mnt/hgfs/thedarkmod$ g++ temp.cpp -m32 -std=c++11 -lstdc++fs user@ubuntu:/mnt/hgfs/thedarkmod$ ./a.out free : 3.53e+09 cap : 1.99e+09 avail: 3.53e+09