stgatilov

Try "r_skipGuiShaders 1" and check if the black quad is gone. Since it overlaps console, I think it is some GUI element, which is for some reason. Also, various backend switches don't help. Also it is worth trying to set "com_smp 0" and "r_useParallelAddModels 0" (this one is "Frontend Acceleration") before the quad appears and see if it will show up again. I have a feeling that when the quad appears, toggling options is already too late.

Here is one way to diagnose the problem. Go to 2.09 beta testing thread, and look at the list of cvars in the first/second post. Try setting them on/off and see which how they affect your problem.

Some sort of TODO: Icons. Some wording improvement (confusion about "Please wait" after installation is complete). Preliminary check of files, in case they are locked by someone. Generate different names for log file, so that they don't overwrite each other.

Ideally, the announcement should link to Downloads page on website. The link to forum thread is unnecessary, and I guess is the result of unnecessary hurry. As for the icon: yes, I will add it.

It is obvious that you used old tdm_update, but it still does not explain why it did not work for you.

If tdm_installer is buggy, then it's hard to be sure in anything. If you share your manifest.iniz, I can inspect it manually, and see if your files are correct (although it is not 100% right approach). It does not know which version you have now (well, almost), so it cannot detect that you already have the newest version. It remembers checksum of every file in every core pk4/zip, and stores this info in manifest.iniz. And if you set "Force scan" or simply delete this manifest.iniz file (better delete .zipsync directory too in such case), then it will forget it and rescan your whole installation. This is also an option, and it won't need much time/bandwidth to try. But better try "Force scan" on the "Bitwise exact zips" checks too.

To everyone for whom tdm_installer does not work. There are several things which can help to diagnose the problem: tdm_installer.log. Unfortunately, it is overwritten on every launch. So if something fails, better rename it to make sure the problematic log survives. manifest.iniz. This file describes precisely the state of your installation (only core TDM files). Contents of .zipsync directory can matter too, especially lastinstall.ini and lastscan.ini. Also, please write your exact OS. As a troubleshooting approach, you can try running tdm_installer with advanced checks "Force scan" and "Bitwise exact zips". But please save the aforementioned files before trying it: if it will help, there would be something to look at at least.

TDM 2.09 is the same, the updaters are different. The new tdm_installer allows being flexible with versions. Having developer builds, easier hotfixes, downgrading to old versions. All that with compact storage and little bandwidth on version switch. The problem is that the old updater is going to be deleted. This is the last version available of TDM via it. If the new one does not work for you, better not delay the inevitable and try to fix it now.

Which of the two updaters did you use? Normally, you can run tdm_installer with advanced checks "Force scan" and "Bitwise exact zips", and you will get exactly the same zip files as on the server. Of course, it won't delete non-game files. So e.g. if you have some additional pk4 files which are not part of TDM, they will remain. You can copy the fms directory from your old installation to the new one. Do the same for DarkmodKeybinds.cfg to copy controls. Yes, the problem is that if you ignore this problem, then all the other people will keep experiencing it.

Could you please change FM to something more standard, e.g. open "currentfm.txt" and write "stlucia" there (without quotes) or "newjob". I see some menu GUI errors in console. Did you mess with main menu GUI in the FM you have installed currently?

Most likely some TDM files were locked by someone. Like running TDM/DR process, or some ghost like antivirus. Perhaps I should implement preliminary touch of all files to avoid such issues. On the other hand, I don't understand how it could produce the error which is shown on the first page. No idea why it is trying to delete base pk4 at this stage. I'd be happy to look at the log, but if you ran installer again after that, then it is already overwritten.

Ehm... I see you are a tech-savvy user if you care about hash verification Normally, you can ignore this hash if you download the program from the official website: www.thedarkmod.com It is there for tdm_installer's self-update: thanks to this file it can learn when new version has been posted on mirrors, without downloading the whole file every time. But if you really want to check it, zsMH is not the name of the hash. The hash is computed with BLAKE2s hash function. Compute if for tdm_installer.exe or tdm_installer.linux64, and it should match.

Closemouthed Shadows is my FM of choice when I need level of minimum size.

You caught me! Something survived indeed.

@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...