stgatilov

We use 1.3.5. The latest stable version is 1.3.6, and 1.4 is not considered stable yet. If authors don't consider it stable, then I'll do the same. Maybe delay this question for a year? It seems that 1.3 branch is not going to have any more releases. Well... what can I say --- that's definitely good for the users It's better if they cannot install TDM to such path, than if they can install but something goes silently wrong afterwards. I think it can be checked on directory selection part: it already marks "bad" path as red, and it can be extended to treat paths with any bad characters the same way.

If I upload it now, then players will play your mission without custom background and with empty briefing until February. Read the original post, it describes where the missions are and when will they be published properly.

Because SVN is used in gamedev, but git is not. Anyway, I'm sick of this question already. Yes, there are plans for official mirror on GitHub for the engine.

Why did you touch tdm_update solutions at all? Just revert the changes. Perhaps it would be easier to put the fix directly into C++ code, by setting #ifdef _MSC_VER for 2019 and above.

I only removed tdm_update.exe, but I did not remove tdm_installer_old.exe --- this one is used now, according to the code. Moreover, the TDM_installer_by_freyk.exe binary that you built does not include it, as seen from its size.

@freyk, I have created another pull request to cover most of these issues. Unless you have any objections, I'll build and publish this version.

Add include <string> I think. As for filesystem, you can probably set _SILENCE_EXPERIMENTAL_FILESYSTEM_DEPRECATION_WARNING define.

Some news about Eigen and build time. I realized rather quickly why my original analysis was wrong. The "Duration" shown for template instantiations in WPA is inclusive, so summing them up is a bad idea. It is especially bad when templates are deeply nested, which is the case for Eigen. It took me quite some time to find a way of computing total impact of Eigen. I had to implement custom analyzer in my fork. Of course, this is not very reliable, because who knows what I did wrong Anyway, here is what it reports for the latest rev: Microsoft (R) Visual C++ (R) Performance Analyzer DEVELOPER VERSION Total time for parsing files matching "*Eigen*": CPU Time: 79.565226 / 96.567721 / 110.676782 Duration: 448.373768 / 1112.570639 / 1168.585713 Total time for template instantiations matching "*Eigen*": CPU Time: 169.516602 / 169.516602 / 170.677942 Duration: 122.637069 / 188.706707 / 190.002096 This time did not limit parallelization, so Duration should be ignored. Every line shows 3 numbers. The first two show total exclusive time spent on Eigen headers/templates. They are computed in slightly different way, and for some stupid reason produce different results The last number shows total inclusive time spent on topmost Eigen headers/templates. If Eigen template instantiation internally causes instantiation of non-Eigen template, then the last number includes the time for that child template, while the first two numbers don't. That's the difference. Here we see that 110s is spent on parsing Eigen headers, and 170s is spent on instantiating its templates. That's 300s in total. Here is comparison of overall stats between the latest revision and the pre-Eigen revision. Full wall time: 164s -> 184s Total CPU time: 840s -> 1270s CPU time of C1DLL (frontend): 650s -> 1052s So, the frontend now takes more by about 400s of CPU time, which increases the total CPU time by 50%. The wall time increases only by 12%. Perhaps that's because the build is not perfectly parallelized, and the old version has more idle time. Basically, the increased CPU load has filled some of the idle time. Here is how CPU usage plot looks like: Maybe the wall time will catch up with CPU time in future, maybe not... Also, since my tool reports 300s spent on Eigen in the new version (instead of 400s), it would be more correct to say that adding Eigen increased CPU time by 33% (instead of 50%).

Tried fixing campaign: No Honor Among Thieves by @Goldchocobo, @Mortem Desino and @Bikerdude. I wonder if any of the original authors is reachable today. This campaign has its own briefing video for each of the three missions. Previously it was done via the "controlled by SDK method", which I'd like to remove. So I had to provide old-style defines instead. Here are my changes in "mainmenu_custom_defs.gui": // stgatilov 5323: use old-style briefing video system instead //#define BRIEFING_VIDEO_CONTROLLED_BY_SDK 1 #if MM_CURRENTMISSION == 1 #define MM_BRIEFING_VIDEO_MATERIAL_1 "video/nhat_briefing_video_politics" #define MM_BRIEFING_VIDEO_LENGTH_1 121509 #define MM_BRIEFING_VIDEO_SOUND_CMD "music video/nhat_briefing_politics;" #elif MM_CURRENTMISSION == 2 #define MM_BRIEFING_VIDEO_MATERIAL_1 "video/nhat_briefing_video_anoott" #define MM_BRIEFING_VIDEO_LENGTH_1 34205 #define MM_BRIEFING_VIDEO_SOUND_CMD "music video/nhat_briefing_anoott;" #elif MM_CURRENTMISSION == 3 #define MM_BRIEFING_VIDEO_MATERIAL_1 "video/nhat_briefing_video_forest" #define MM_BRIEFING_VIDEO_LENGTH_1 34600 #define MM_BRIEFING_VIDEO_SOUND_CMD "music video/nhat_briefing_forest;" #endif Also I commented out the MM_BRIEFING_VIDEO_MATERIAL_X, MM_BRIEFING_VIDEO_LENGTH_X and MM_BRIEFING_VIDEO_SOUND_CMD defines in the rest of the file. It works for me now. Unfortunately, the briefing won't work in 2.09 and earlier versions: it simple displays black screen, waiting for player to click mouse button.

I think FXAA should be much worse in TDM than even the lowest levels of multisampling. Regarding the geometry, there are two opposite sides of the spectrum: blocky geometry with long straight edges (vertical/horizontal) and large triangles curved surfaces with many small triangles and no apparent directions FXAA probably helps with case 2 well, but case 1 is much harder. I had such case on my daily job, where buildings without any details were rendered without textures and with single color (very blocky style). Even the latest FXAA on highest quality did not help: the long vertical edges still looked awful when moving. And multisampling was mutually incompatible with SSAO due to shitty WebGL Perhaps FXAA and other alternatives are newer, but multisampling is the "correct" approach, while FXAA is not. It matters a lot what information is used by antialiasing method: multisampling saves the real coverage information, which makes it converge to perfect image as you increase number of samples. FXAA does not use any additional information, so it is pure guesswork and hacking. Temporal antialiasing uses information about velocity, and I think this information allows it to achieve good quality: it knows how current frame relates to the previous/next ones, so it blurs in such a way that pixels don't jump back and forth as you move.

The next one is "Accountant 1" by @Goldwell. It was overriding some things in order to change background and to hide briefing. I have removed the overriding files, and added the following to "mainmenu_custom_defs.gui": //stgatilov #5323: disable briefing state #define ENABLE_MAINMENU_BRIEFING 0 //stgatilov #5323: override background everywhere #define MM_BACKGROUNDS_MAINMENU_NOTINGAME BackgroundCustomAccountantGears #define MM_BACKGROUNDS_EXTRAMENU_NOTINGAME BackgroundCustomAccountantGears #define MM_BACKGROUNDS_MAINMENU_INGAME BackgroundCustomAccountantGears #define MM_BACKGROUNDS_EXTRAMENU_INGAME BackgroundCustomAccountantGears #define MM_BACKGROUNDS_BRIEFING BackgroundCustomAccountantGears #define MM_BACKGROUNDS_DIFFSELECT BackgroundCustomAccountantGears #define MM_BACKGROUNDS_SHOP BackgroundCustomAccountantGears Then added "mainmenu_background_custom.gui" with animated background image.

Yes, I usually get something near 1 MB/s for full installation, which gives expected time of about one hour. Maybe one day I'll implement parallel requests (to same or different mirror). Thus far I'm worried about consequences (refactoring too much or multithreading issues). Luckily, you have to wait for a long time only once, the version switches are pretty fast after that.

Next case is March of Rahena by @ERH+. Again, no bad overrides here, but I'd like to remove "custom title" feature, which is used here to replace background. As far as I remember, @ERH+ agreed to change the way how background looks. Here are my changes: Added mainmenu_background_custom.gui with one background layer for the actual image. Commented using #if 0 the group of defines related to custom title. Added the code to override background in main menu: #define MM_BACKGROUNDS_MAINMENU_NOTINGAME BackgroundCustomRahena #define MM_BACKGROUNDS_EXTRAMENU_NOTINGAME BackgroundCustomRahena #define MM_BACKGROUNDS_MAINMENU_INGAME BackgroundCustomRahena #define MM_BACKGROUNDS_EXTRAMENU_INGAME BackgroundCustomRahena Since custom briefing uses default TDM backgrounds in this FM, I did not override background for DIFF_SELECT state: it uses TDM's default too.

If it will be a small change, then OK. But if it needs substantial changes, then I'd say better don't.

It is better to not show any support (since OS does it perfectly) than to do it poorly.

I'm pretty sure everyone with 4K display is used to seeing upscaled applications. If something was not updated, or developers don't care (like me), then it works in default upscaling mode. Anyway, FLTK renders all its GUI manually, so high DPI support must come from the library. I guess here is the page, saying "FLTK supports high-DPI screens using a screen scaling factor". I think it either looks the same as with OS scaling, or it looks even worse due to some stuff getting thinner.

The next case is Score to Settle FM by @Springheel. This one does not override anything inappropriate, but it uses debriefing (controlled by SDK), which I'd like to get rid of. This case is rather strange, because I had problems checking its behavior. I used "tdm_end_mission" command to quickly win, and tested 2.09, then 2.06, then 2.05. The debriefing simply did not trigger for me in 2.09 and 2.06, but it triggered in 2.05 --- however, it was without sound (main menu music kicked in immediately). Then I retried 2.09 and debriefing worked this time, but again with main menu music. I assume that the intent is to play debriefing video with its sound. I guess this story confirms the idea that rarely used stuff breaks without anyone noticing it sooner or later In this FM, I have only added the following defines in mainmenu_custom_defs.gui: //stgatilov #5323: enable and configure debriefing video #define ENABLE_MAINMENU_DEBRIEFING_VIDEO 1 #define MM_DEBRIEFING_VIDEO_MATERIAL_1 "video/tdm_final_vid" #define MM_DEBRIEFING_VIDEO_LENGTH_1 43000 #define MM_DEBRIEFING_VIDEO_SOUND_CMD "music tdm_video_finalroq_1;" This does not affect its behavior in 2.09 and earlier, but fully fixes the debriefing in the test version of TDM.

Yes. Since there are no special things in the installer for high-DPI case, I assume the OS should consider the tdm_installer as DPI-unaware and scale it automatically. So it wouldn't be tiny on 4K screen. Yes, it will be a bit blurry, but that's not a problem: it's not a game with crisp graphics. Maybe this is possible. I'm not sure FLTK supports it, but maybe it can be wrapped into OsUtils and called in progress callback.

I think as soon as someone installs real Windows or Linux on the console, TDM should work out-of-the-box. Basically, it becomes the officially supported platform then. However, I'm skeptical about performance.

If tolerance for checking parallellity is much larger than error, then it should be OK. On my daily job people use angular tolerance 1e-10 or 1e-9, in which case O(sqrt(eps)) error is unacceptable. As for rotation matrix for two ?vectors?, again it depends on how much error you can cope with in the rotated data. Yes. If the rotated coordinate is about 5000, then 3e-4 error in the angle gives 1.5 error in the result. Which is a lot. I understand. However I can say the same about doubles: float gives 1e-7 relative precision, which is absolute error at most 0.01 doom units for levels of sane size. So single precision floats should be enough for you... but it is not enough for some reason, right? Having O(sqrt(eps)) error with double-precision vectors is like using single-precision vectors. Of course, the problem only triggers when you have small angle, which can happen very rarely in some cases (but very often in other cases).

Here is the code for computing angle: /// Return the angle between <self> and <other> T angle(const BasicVector3<T>& other) const { // Get dot product of normalised vectors, ensuring it lies between -1 // and 1. T dot = std::clamp( getNormalised().dot(other.getNormalised()), -1.0, 1.0 ); // Angle is the arccos of the dot product return acos(dot); } This approach gives high error for small angles (i.e. when cosine is close to 1.0 or -1.0). If machine epsilon is eps, then error can be as high as O(sqrt(eps)). For floats, it would be about 3e-4, and for doubles, it would be about 1e-8. It can be good idea to use asin/acos to compute angle only if you prefer speed over precision. In order to achieve O(eps) precision for all angles, use atan2: return fabs(atan2(a.cross(b).length(), a.dot(b))); This approach also works perfectly well for computing signed angle in plane --- just remove fabs and replace .length() with dot product over plane normal (direction matters).

I have inspected the revision just before Eigen was added the same way I did with master. As expected, parsing takes 128s instead of 172s, and template instantiation takes 121s instead of 605s. However, exclusive duration for C1DLL goes down from 785s to 514s and CPU time goes down from 608s to 473s. The expected -500s difference is not here. Moreover, the version without Eigen has 5% difference between CPU time and exclusive duration, while the version with Eigen has 20% difference. I suspect that some data in the story cannot be added together, e.g. time for template instantiations. And now there is question what took half of frontend time before Eigen, given that Parsing and Template Instantiations summed together only take half of it. Most likely I'm doing something wrong. I already have an answer, now I need to find the question

Perhaps PCH in GCC are simply worse. Precompiled header in MSVC is implemented via memory dump of compiler done at the end of processing the header. When it is used, this saved state is simply loaded from disk (most likely mapped) and processing continues from that point. That's rather barbaric approach, and it does not work for C++ modules (which act like modular PCH), but it should be perfect in terms of performance.

Yes, simple templates usually don't cause much trouble. But Eigen is most likely designed for large matrices, and all the complexity is worth it when you deal with 500 x 500 matrices. Instantiated templates are not reparsed today, although MSVC did it for many years. However, every call site where template code is inlined has to be compiled again and again, there is nothing to reuse there. Also, they have to be recompiled in every translation unit, because that's what separate compilation model requires. It is possible to instantiate template code only once using extern template. However, you lose inlining this way too. You don't need inlining for SVD and for decomposing matrix into translate + scale + rotate. These operations are slow anyway, lack of inlining whole be noticeable. Inlining is very important for trivial things like adding, multiplying, dot products, etc. Just write three additions in header and everything would be OK. Don't use Eigen for that.

Some time ago I wrote this article. Basically, both bugtracker and TDM Tech Support forum are OK. However: Bugtracker is usually for the cases when you are sure this is a bug. Issues in bugtracker (outside of current roadmap) have tendency to be overlooked. There is so many of them, and I'm afraid no one monitors for new issues. Forum is much better to get fast response. It is better for talking in general: bugtracker is mostly for technical discussions. So I'd suggest Tech Support forum.