stgatilov

Fixed that. Emm... it means that static libs for OpenAL and pugixml use some symbols which your VC/CRT installation does not provide, or something like that. I'd say that's not something for non-professional C++ programmer to debug This might happen because of wrong VS version. If you have some VC projects/solutions open, close all of them. Use SVN client to ensure that TDM source repository is perfectly clean, i.e. there are no local changes in any files (especially in .sln and .vcxproj files) Make sure to open the solution in 2022 version of Visual Studio (especially if you have not deleted version 2017 yet). Try to rebuild whole solution.

The problem of dependencies is quite severe on Linux. We minimize it by linking almost everything statically, except for OpenGL and glibc. I'd be happy to link glibc statically too, but it does not work So instead I simply build official binaries on a pretty old Linux distro. Flatpak solves the glibc problem at least. Speaking of checksum. If you absolutely need one, you can bundle tdm_installer archive with the manifest. Then checksum will not change. And the installer should self-update to the latest version anyway on the first run. That's how @freyk does it in his installers. As a user, I'd be happy to forbid programs access to anything outside their directory, but I doubt they will work properly after that I hope TDM does not break from this restriction: in my opinion, it should never go outside installation directory (unless the user tweaks some filesystem cvars that should not be changed). Additional 100-200 MB is not a problem at all for a 3GB+ game. I think I should try to install flatpak and install TDM via it myself. I must admit I don't want to maintain anything like this myself. However, this manifest basically wraps our official installation instructions, seems to require almost no maintenance, and allows to publish TDM on a well-known distribution system without legal burden (like on Steam).

Welcome to forums! Thanks for sharing this! The main problem with having more ways to install/build TDM is maintaining all of them, and making sure players don't get into more problems. That's why we keep away from having official TDM packages in Linux distributions and similar stuff. Is there any benefit in this flatpak approach, compared to running tdm_installer manually? P.S. You should not specify checksum for tdm_installer.linux64.zip, because this file is regularly updated, and each update changes the checksum.

Can you at least provide the pkg-config code that you use? Preferably for all third-party libs used, except for probably header-only ones.

I assume pkg-config defines the same variables like openal_INCLUDE_DIRS and openal_LIBRARIES ? Since some packages have different names, the pkg-config path needs to do set a few cmake variables too, so that the rest of the CMake file could use conan names. And the last question is: whether it should be put straight into CMakeLists.txt, or it should be put into ThirdParty/cmake_find_package/FindXXX.cmake. The second option is probably better, but means a bit more bolierplate (basically the same "if" and the same "include" in every "find" file).

Is it true that pkg-config provides more libraries or does so more accurately than cmake's built-in find_package? (at least on Unix-like systems)

Oh... I thought pkgconfig is something installed as system package, which knows how to find many libraries by their standard name. If you have to write this UsePkgConfig.cmake yourself, and enumerate all libs there, then there is absolutely no point in using it: why not do the same with cmake?

Speaking of CMakeLists changes, you can minimize the changes on your side, then share the patch. I'll see what you had problems with. Maybe I'll find a better way to fix something, maybe I'll apply it "as is" under appropriate option.

Applied the second commit as svn rev 9892. Also, I accidentally noticed that tdm_installer build is now broken because I changed the name of curl cmake package, so I changed that. We take libs from conan, so we have to use its convention: now we do "find_package(CURL)" everywhere.

I applied the first patch with minor changes in svn rev 9890. Regarding the second one: Why did you add cast to (const uint8_t *) in Hasher::Update? It seems that blake2s_update accepts const void * regardless of platform... UPDATE: It turns out that older versions of BLAKE2 received const uint8_t * (commit).

Because inlined geometry of a model goes through dmap processing. The more such models you have, the longer dmap takes. Chance of complicated geometric algorithms failing also increases. Are there any benefits of inlining? One less entity is not a reason any more (and probably combining close models into one is better than inlining models). Yes, dmap can remove some invisible geometry and precompute stencil shadows. But with the costs outlined above.

If you travel by air, then you have to fill customs declarations when you come to a foreign country. Or go through green corridor, implicitly saying that you have nothing to declare. It has nothing to do with airlines. Given that we will have two laptops and a miniPC for three people, I think carrying excess computer parts can cause issues on the customs. As far as I understand, one laptop per person is considered OK by customs, but not more.

At this moment I consider two options: Send it via international post to one of my future colleagues Take it with me to airplane I'm only considering taking the chassis and everything inside it. I'll definitely let monitor, keyword/mouse, speakers rot. Regarding international post: does anyone have experience sending PC abroad? I'm trying to understand how to fill customs declaration, and how to specify cost. For instance, how to estimate cost of component which is no longer sold (the oldest piece is SB Audigy 4, which is about 15 years old)...

You need to pass +set com_allowConsole 1 as command line parameter. You can create shortcut of batch/shell file for that. Changelog is at the top of this thread, as usual.

Ok, it seems that while using EXE as DLL is possible, some pretty artificial issues make this path very hacky: https://www.codeproject.com/Articles/1045674/Load-EXE-as-DLL-Mission-Possible And adding optional build with DLLs but deploying fully static build would mean that you'll have to distribute this DLL yourself, i.e. you cannot load this DLL from user's TDM installation.

One of the problems with DLL-based build is having to use dynamic CRT (recall the nightmare of two separate CRTs when Doom 3 was closed source). In this case we have to do one of: Put CRT dlls into game directory. This was not an option before 32-bit deprecation because it did not allow 32-bit and 64-bit executables to coexist in the same directory. And changing paths conventions in TDM is something I'd better not attempt Run VCRedist installer on player's machine. I tried doing that but it did not work well... Maybe because I wanted to avoid running the installer when it's already installed, and I did not manage to properly check if compatible version is installed. Anyway, there were a lot of complaints about this thing, so I simply returned full-static build. Maybe it is possible to have an option (CMake-only) to build something dynamic, but that option would probably get broken regularly, because everyone would forget about it. Yes, it makes sense to keep interface pure-C. You won't be able to dynamically load exported C++ function because of name mangling anyway. But are you sure you will be able to expose much stuff without using complex types? By the way, it is not necessary to create any kind of DLL to do that. In principle, DarkRadiant can import the EXE file as module and use its exported functions! After all, entry point is the only difference between DLL and EXE. Of course, doing so would mean mapping 18 MB file onto DR's virtual memory, but I don't think it is a big problem (well, maybe code cache would suffer because relevant TDM functions would be less localized). Running dmap is now available with the "game connection" feature. Of course, it is more messy and fragile than DLL call, but "game connection" needs to exist anyway (and dmapping in game connection is a bit faster). Ehm... To be honest... we discussed that we should probably reimplement most of this system But I agree that it would be very hard to force myself doing that It seems that writing English full-text in translation files instead of relying on these #str_XXX keywords would be more comfortable for mappers in 99% of the cases, and additional "labels" added to the original text would resolve ambiguity in the rest 1%.

I think dmap uses materials/decls/images only because materials are assigned to geometry. In fact, it does not need actual images, it only needs material flags to determine if material is opaque or not. Of course, you will have to drag along the whole idlib, and probably all the common/sys classes as well: idList-s are now all over the place, and various common->Printf/Warning are used a lot too. By the way, recently I merged idlib code into TDM project... and most likely it has to be extracted back in order to be used in DarkRadiant. On the other hand, won't moving dmap to DarkRadiant cause more problems than if would solve? For instance, dmap sometimes is changed. One such change during 2.08 was quite breaking. Dmap from TDM is not compatible with dmap from Doom 3 and vice versa (a map which compiles on one game can fail with leak on the other one). How would mappers understand which version they use? What if dmap changes are tied to the changes in the rest of the game? Extracting renderer frontend would be much harder I suppose. Without it, you can just read .proc files and implement your own areas/portals pruning code.

Created and fixed: 5928 After inspecting this savegame and finding the most likely cause, I found a reliable way to reproduce it. It only happens if you load the game in a fresh TDM process, and if you saved game while holding/stringing the bow. Hopefully, this won't happen in future dev builds and in 2.11. Also, there is a minor probability that this change will fix crashes too, if they happened due to thread-unsafety of cvars system.

Putting a kid into luggage indeed saves from a lot of headache Maybe I'll ask someone to ship my PC to me, but this is rather unlikely.

dev16481-9881 is available. There are two reasons for this dev build: major update of compiler and third parties releasing all the changes which happened during 2.10 beta but did not get into release

Relocation. The only way to take the desktop PC is to take it along with me on the flight (as luggage), but I'm pretty sure there would be a lot of other things to carry.

Did you mean discrete graphics card?

Post the savefile. Of course, that would only help if it is reproducible from a clean TDM run. UPDATE: Also, you can record crashdump, upload it somewhere, and share the link.

I will probably have to get rid of my desktop PC, and I'm worried about how to work on TDM without it. Obviously, I need a laptop, but: Laptops without discrete GPU will probably run TDM too slowly. Can anyone share positive experience about that? Laptops with discrete GPU (gaming laptops) are often unreliable. I'm worried that they die too quickly...

Sounds like a partly updated mirror?...