Search the Community

https://stadt-bremerhaven.de/nvidia-veroeffentlicht-quelloffene-linux-kernel-treiber-fuer-seine-gpus/

I don't think this counts as a bug but maybe it's something to look at... Nvidia GPU, Intel CPU Linux: Scroll of Remembrance - Shadowmaps ( size 1440 ) 70+ FPS / Stencil 58+ FPS Windows: Shadowmaps ( size 1440 ) 52+ FPS / Stencil 30+ FPS I am guessing we can mostly attribute this to Windows CPU usage bloat. Can any other dual-booters confirm? Edit: I went back to check my Windows security "Exploit Protections" area for "TheDarkModx64.exe" to see if it still existed and still had most of the protections disabled and found some new protections were added. I disabled "Heap Protection" and: Shadowmaps 58+ ( mostly 60+ ) / Stencil 38+ ( mostly 40+ ) ( All the FPS are at the start of the mission facing the manor, eg worst case scenario ).

Also, I think the save restriction currently doesn't work (properly) in Linux (at least 2 users now I think), giving a crash-to-desktop. Would be nice if more Linux users could test and confirm this. I think you could add a different starterlocation (2.12) in the gui (but just present it as an expert mode, not a location) and then at the different starter-location (which is positioned close to the standard one), you put a triggerbox (only triggering that starterplayer) with a script attached that makes the necessery changes right at mission start. Making it show up in the difficulty selection means you have to override that core gui file though I guess.

Can anyone help with the following? When running make, I get this when it gets to OpenGLRenderSystem: Never mind. I built it again without errors.

I'm definitely interested in this. In the past it used to worry and upset me that some of the assets are CC-BY-SA-NC: Not because I'd care to sell them in any conceivable format, but because it made the project seem less libre and FOSS and Linux friendly. I remember my only disagreement was with some developers being against FM authors taking donations for their own work on their personal maps and stories, I think that's more problematic but ultimately accepted and respected it since to me that's secondary and I'm just happy TDM and DarkRadiant exist for us all to create worlds with. As stated before, many of the existing assets would need replacements that look the same way. Since the authors of old FM's can't be expected to re-texture all of their maps, those replacements would need the same names or an automatic conversion script, and have to look in such a way that they fit the old textures just right at any transformation. This isn't impossible but something I find unlikely as few people willing to do the effort may find it useful enough to work on one. Such a transition could perhaps be considered if we ever switch to high-res textures: Many of the images could be upgraded with replacements someday... maybe this time we can avoid going for semi-libre assets and use fully FOSS compatible ones. I've also been dreaming of a cyberpunk conversion for years, to have a TDM that's less Thief and more DeusEx taking place in a futuristic environment... also unlikely to happen but the hope in my attempt was to ween off of the stricter assets.

The devs didn't title this thread, and @datiswous said they're attempting to mislead people by using Russell's name and a retro style to make it resemble Thief, which is cynical. I grew up on forums like I'm sure anyone who likes a game from '98 did. I actually left the Discord immediately after joining it because it was more off-topic doom-posting than anything relevant to the mod. I thought the forums might be better, but it's mostly just grown men yelling at clouds and telling strangers how mature they are, and a few brave souls actually developing anything. Depressing place, I'll just stick to enjoying new missions every 6 months without an account.

True, but, 1. this thread is called "Western stealth FPS with Stephen Russell", and, 2. nothing you said changes anything for me. The gameplay still doesn't look like something I'd enjoy. And, if you really think this forum is cynical, then you don't visit forums much. Actually, the majority of the users are are pretty mature, unlike in other forums.

Also unable to reproduce, Linux Mint 21.3 Virginia. Nvidia Geforce RTX 2060 latest non-free 535 drivers.

We didn't make the holidays (such a busy time of year) so here's a New Year's gift, an unusual little mission. Window of Opportunity Recover an item for a regretful trader out in a wilderness setting, and discover more! Available within the in-game mission downloader or: Download: http://www.thedarkmo...ndetails/?id=79 Alternative: https://drive.google...WTMzQXZtMVFBSG8 Some unorthodox gameplay on regular/ghost difficulties. (Arachnophobes might prefer short mode...) Please expect to need your lantern in regular and ghost modes! Short ("easy") mode is a smaller map, so if you are looking for areas others reference below, or 100% of the loot, you'll need to play on another mode. I wanted to create my first mission before I became influenced by too many others' ideas, and limited myself to what has been done before. As such, this mission is not set in a city/town, and has some features that are likely to be provocative. There's a section some really like, which others don't, either way I kept it short to not last too long. That being said, I hope you do find it fun! :-) Special thanks to those who provided valuable testing and feedback: Goldwell, Kyyrma, plotzzz, 161803398874989, PPoe & Bikerdude (who also contributed a sound). (Please remember spoiler tags to not expose things meant to be discovered by playing.) Like so: [spoiler]secrets[/spoiler] If you are having trouble finding the main objective, here's what to pay attention to in the mission for hints: There is a spot it's possible to get stuck on the ground in the corner by the cliff/rockfall where there's a rope laying on the ground, please take care if you poke around there!

Antialiasing mostly affects some backend logic, while the commit changed data structures in frontend. It is very hard to believe they are linked in any way. Maybe the bug is not reliably reproducible? Maybe antialiasing is an important condition when it happens, but otherwise it is timing-specific, so accelerating frontend made it pop up. Or maybe antialiasing is just one way to slow gown backend and using maximum soft shadow quality or r_fboResolution 2 would make it happen too. Maybe the particular behavior is driver-dependent (e.g. NVIDIA masks the error away). Which GPU do you have? Which drivers do you use? Which CPU do you have BTW? I cannot reproduce it myself, even on Linux VM. Does it happen in the very specific viewpos and goes away if you move away slightly? Maybe someone else can reproduce it?

I deleted double-slashes in svn rev 16957. I think they were causing the issue. I believe it only happens on Linux, Windows side somehow reduces the double-slash to single directory separator.

New script for mappers: my flavour of a fog density fading script. To add this to your FM, add the line "thread FogIntensityLoop();" to your map's void main() function (see the example in fogfade.script) and set "fog_fade" "1" on each foglight to enable script control of it. Set "fog_intensity_multiplier" on each info_location entity to change how thick the fog is in that location (practically speaking it's a multiplier for visibility distance). Lastly, "fog_fade_speed" on each foglight determines how quickly it will change its density. The speed scales with the current value of shaderParm3, using shaderParm3 = 1000 as a baseline. So i.e. if shaderParm is currently at 1/10th of 1000, then fade speed will be 1/10th as fast. Differences to Obsttorte's script: https://forums.thedarkmod.com/index.php?/topic/14394-apples-and-peaches-obsttortes-mapping-and-scripting-thread/&do=findComment&comment=310436 my script uses fog lights you created, rather than creating one for you. Obsttorte's script will delete the foglight if entering a fogfree zone and recreate it later more than one fog light can be controlled (however, no per-fog-light level of control) adding this to the map requires adding a line to your void main() script, rather than adding an info_locations_settings entity with a custom scriptobject spawnarg in my script, mappers set a multiplier of fog visibility distance (shaderParm3), while in Obsttorte's script a "fog_density" spawnarg is used as an alternative to shaderParm3 smaller and less compactly written script fogfade.scriptfogfade.map

Thanks. Linux user and I play TDM at least weekly: Never noticed any physics issues myself, whatever happened in the FM must be a relatively rare scenario... that's a FM I haven't revisited so I was lucky to miss the bug then. There is in fact a little problem in latest Beta, though it's so small I didn't bother to document it carefully, but I'll share the idea of it at least: If you climb into a tight space between an object and the ceiling and turn on the flashlight, jumping may cause the light to phase through the floor and disappear temporarily. Say you have a crate pressed against a ceiling where you can only climp and go in while crouched... if the surface is high enough to allow a jump but just low to force you to be crouched, you'll see the light source of the lantern disappear temporarily in mid air. Think I saw it in The King Of Diamonds, if it's important I'll boot it up again and noclip to get a viewpos. Just to make sure you've seen my mention: Please check my message a few posts above where I attached a log, we have a crash where killing AI with a broadhead arrow can cause the engine to go down with a "tried to free uncached trace model" error... not even a main menu crash but one to the OS. It's pretty rare but if you fatally shoot AI often enough it will occur eventually.

Greetings. First I would like to say a huge thanks for the continued support of this game and for TDM 2.10, it loads much MUCh faster now. However on Debian Linux I have an issue where the mouse occasionally just warps. It happens both in the game and in the menus, though obviously when it happens in the game it is quite disorienting. Anyone else experience this? I never saw it in 2.09... EDIT: Seems to have gone away when I switched window managers.

Thanks for doing the digging. Libxml2 is so widely used, that it's hard to imagine nobody else has this kind of trouble, so I'm still thinking it must be in the way we use it. Also, why just in Linux, it all doesn't make much sense. I agree it's not worth doing more investigations when an easier alternative is at hand. Yes, I'd add them to the libs, and I'm probably going to set the PUGIXML_HEADER_ONLY flag, at least in Windows.

High-NA EUV is obv independent of the substrate. It's going to get used regardless. The scenario where it doesn't get used is if an older process node could be used, which was one of the ideas behind nanotube-based 3DSoC. So, the brand new Ryzen 8000G desktop APUs are out. The consensus is they don't make sense compared to CPU + dGPU: https://www.tomshardware.com/pc-components/cpus/amd-ryzen-7-8700g-cpu-review https://www.techspot.com/review/2796-amd-ryzen-8700g/ https://www.anandtech.com/show/21242/amd-ryzen-7-8700g-and-ryzen-5-8600g-review https://www.phoronix.com/review/amd-ryzen7-8700g-linux https://arstechnica.com/gadgets/2024/01/ryzen-8000g-review-an-integrated-gpu-that-can-beat-a-graphics-card-for-a-price/ Gamers Nexus video review Neat though.

Hi, I'm trying to make some maps for dhewm3, but if I give the path where the game files resides it crashes. In my case the path is /usr/local/share/dhewm3/ This doesn't happen if I give it my working path but then I'm missing all definitions, models, materials etc.. ~/.local/share/dhewm3/ My system is Ubuntu 20.04, DarkRadiant 3.2.0 is installed from ppa This is the error: $ darkradiant SIGSEGV signal caught: 11 0: /usr/lib/x86_64-linux-gnu/darkradiant/modules/libradiantcore.so(_ZN6applog15SegFaultHandler14_handleSigSegvEi+0x474) [0x7f7b3f2ebef4] 1: /lib/x86_64-linux-gnu/libc.so.6(+0x43090) [0x7f7b524ce090] 2: /usr/lib/x86_64-linux-gnu/darkradiant/modules/libradiantcore.so(_ZN4decl23DeclarationFolderParser5parseERSiRKN3vfs8FileInfoERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x202) [0 x7f7b3f1abf32] 3: /usr/lib/x86_64-linux-gnu/darkradiant/modules/libradiantcore.so(_ZN6parser18ThreadedDeclParserIvE12processFilesEv+0x87b) [0x7f7b3f1b9f8b] 4: /usr/lib/x86_64-linux-gnu/darkradiant/modules/libradiantcore.so(_ZN6parser18ThreadedDeclParserIvE7doParseEv+0x20) [0x7f7b3f1bb140] 5: /usr/lib/x86_64-linux-gnu/darkradiant/modules/libradiantcore.so(_ZNSt17_Function_handlerIFSt10unique_ptrINSt13__future_base12_Result_baseENS2_8_DeleterEEvENS1_12_Task_setterIS0_INS1_7_Resu ltIvEES3_ENSt6thread8_InvokerISt5tupleIJZN6parser17ThreadedDefLoaderIvE19ensureLoaderStartedEvEUlvE_EEEEvEEE9_M_invokeERKSt9_Any_data+0x50) [0x7f7b3f1d1e20] 6: /usr/lib/x86_64-linux-gnu/darkradiant/modules/libradiantcore.so(_ZNSt13__future_base13_State_baseV29_M_do_setEPSt8functionIFSt10unique_ptrINS_12_Result_baseENS3_8_DeleterEEvEEPb+0x2d) [0x7 f7b3f1c6f2d] 7: /lib/x86_64-linux-gnu/libpthread.so.0(+0x114df) [0x7f7b5268e4df] 8: /usr/lib/x86_64-linux-gnu/darkradiant/modules/libradiantcore.so(_ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJZNSt13__future_base17_Async_state_implINS1_IS2_IJZN6parser17ThreadedDefLoad erIvE19ensureLoaderStartedEvEUlvE_EEEEvEC4EOSA_EUlvE_EEEEE6_M_runEv+0xfd) [0x7f7b3f1ca13d] 9: /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0xd6de4) [0x7f7b528e2de4] 10: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f7b52685609] 11: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f7b525aa133]

Cheers! I've been wondering for some time now if it would be possible to compile the source code of TDM to the Raspberry Pi, especially the models 3 and 4. I've seen some videos online of people running Doom3 on it, so how hard would it be to compile the source of TDM for the raspberry pi? Would it need a major rewrite of some parts of the code? I've been "tinkering" with the source for some days, and as I was expecting, all the configuration files are made for x86 architectures (Linux and Windows). I've been searching online for some info about the toolchains needed to even start compiling the source for these arm machines, but the information has been quite lackluster and outdated. I've managed to track down a toolchain to compile c++ code for the raspberry pi, made by the pi foundation but I'm not quite sure how to use it and I guess the support for it has been dropped for quite some time now. Anyway, I figured that instead of wasting more of my time, it would be best to ask here what you guys think. Is it possible to even think about this, or does TDM use some kind of libraries or other external code which makes it impossible to compile for the pi? Is there anything related to the game that makes almost impossible or too much of a hassle to try to port the game for the raspberry pi? Performance isn't an issue for me. I just want to know if it can be run in that machine. If it is possible to do this without a major code rewrite of the game, where should I start? I have no experience on compiling anything for arm, only some experience in x86, so this might be a fool's errand, but I would like to give it a try nonetheless. If it is possible to do this and if some of you could help me in any way, that would be appreciated. On the other hand, if you think this is a really hard thing to even try to do, please feel free to tell me so I don't waste more of my time. Thanks in advance

Beta 11 Fix finished-on state auto-update was unreliable Slighty improve scanner title/author detect Tags are now named some whatever regular-version-looking thing to force GitHub to put the newest at the top

That was fun! A very impressive, sprawling map with lots to do. Love it! I did get stuck with ...For whatever reason, my installation is one where you don't fit through the gap in the wall, and the peepholes don't work either. (Yes, it is Linux) I never did find But I did manage to figure out 3 of the 4 Good Deeds unaided.

I ran into an error when compiling The Dark Mod on Linux with glibc 2.34. Building CXX object CMakeFiles/TheDarkMod.dir/tests/TestRun.cpp.o In file included from /home/dm/darkmod_src/tests/testing.h:22, from /home/dm/darkmod_src/tests/TestRun.cpp:18: /home/dm/darkmod_src/ThirdParty/artefacts/doctest/include/doctest/doctest.h:3998:47: error: size of array ‘altStackMem’ is not an integral constant-expression 3998 | static char altStackMem[4 * SIGSTKSZ]; | ^ make[2]: *** [CMakeFiles/TheDarkMod.dir/build.make:3071: CMakeFiles/TheDarkMod.dir/tests/TestRun.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/TheDarkMod.dir/all] Error 2 make: *** [Makefile:103: all] Error 2 Updating "ThirdParty/artefacts/doctest/include/doctest/doctest.h" to 2.4.8 fixed it for me. https://github.com/doctest/doctest/blob/v2.4.8/doctest/doctest.h See "Can't compile with glibc master (future 2.34): SIGSTKSZ is no longer a constant" (https://github.com/doctest/doctest/issues/473)

I did some debugging in unit tests. The first problem is that although we have a basic XmlTest, it uses the full RadiantTest fixture which can only be constructed if the XML registry is working fine, so these basic XML tests are not runnable. I managed to fix that by changing the behaviour (on Linux only) to use TEST_BASE_PATH instead of _context.getTestResourcePath() to find the test resource files, so that RadiantTest is not required. This confirmed that the basic functionality of loading XML is working perfectly fine, even with the switch to xmlReadFile(). All of the XML tests pass, and I can load one of the game files in a unit test and examine its properties. So there is nothing fundamentally wrong with the XML structure being created by the new function call. The problem seems to be that within the Game class, any attempt to look up key values in the registry fail. Although each Game class is constructed successfully and imports its content, any searches for its own XPath root (e.g. "//game[@name='Doom 3 Demo']") return a list of 0 nodes, even though that exact XPath string can be used successfully within the basic XML test to find the <game> node which was loaded directly into an xml::Document. So there must be something going wrong with either when or how the .game file content is being merged into the global registry hierarchy.

I beta tested A Night in Altham again and found a few engine related issues. First off the new "screenshot_viewpos" command doesn't actually show the viewpos, it makes the console appear in the screenshot but the view position doesn't make it in in the frame. Here is an image taken with this command: It doesn't seem like a clean solution to make the whole console appear anyway: I wonder if it's possible to make just the viewpos appear at the top of the render in a special display with this command. Also this FM was a good occasion to test peeking. Thankfully it no longer crashes the engine on Linux or what the old problem was. Problem is that everything's black instead: You see nothing while peaking, just parts of the keyhole overlay and that's it. Thus peaking remains broken, whether this issue is also Linux only or not.