Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Content Count

    4308
  • Joined

  • Last visited

  • Days Won

    88

Everything posted by stgatilov

  1. Hey, do you still have some map which shows the original problem? The warning itself happens occasionally (I guess Painter's Wife had a bunch of them), but printing random numbers is definitely not good. In any case, I think it is worth looking at.
  2. Anything. If you want to mess with it now, you can download artefacts for 1.4 from somewhere, and play with it. But I'm quite against committing FLTK 1.4 to SVN at this moment. Of course, if your changes to installer code happen to be small and simple, you can commit them to SVN under some ifdef (maybe FLTK even provides a macro for checking its version), so that they can be enabled later.
  3. 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 w
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. @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.
  9. Add include <string> I think. As for filesystem, you can probably set _SILENCE_EXPERIMENTAL_FILESYSTEM_DEPRECATION_WARNING define.
  10. 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) Perf
  11. 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_MATERIA
  12. 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: th
  13. 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_BACKGROUND
  14. 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.
  15. 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_NOTINGA
  16. If it will be a small change, then OK. But if it needs substantial changes, then I'd say better don't.
  17. It is better to not show any support (since OS does it perfectly) than to do it poorly.
  18. 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.
  19. 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 ass
  20. 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.
  21. 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.
  22. 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 u
  23. 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 h
  24. 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 instantiatio
  25. 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.
×
×
  • Create New...