Search the Community

The way that input and windows are managed for Linux has become rather dated, causing a multitude of issues. To fix that, I am currently evaluating if we can just use a library (GLFW) to handle all of that for us. First impressions are rather positive, on my end I see generally improved behavior. However, since Linux is a rather diverse ecosystem, I need additional testers to rule out I broke something important. So if you have some time to spare, I'd appreciate it if you could give this build a try: https://ci.appveyor.com/api/buildjobs/6kbqskyx3tmla74s/artifacts/build%2Fthedarkmod.tar.bz2 Just extract to your installation, delete your darkmod.cfg and give it a spin. I'm particularly interested in input and alt-tabbing behavior. Whether it improved something for you or broke something. Thanks!

@MirceaKitsuneThanks for the playthrough and feedback! In recent memory my mapping efforts have gone to new projects that I feel more inspired for - I think they would probably also be more interesting to the broader TDM community. The fix to Linux users getting stuck at map start was fixed in 12-06. The FM update only covers datiswous' new subtitles and an early attempt to fix the stuck bug by moving the player start a few units. The ship was made from scratch for this FM with an exterior and interior. It's my first ship asset and I've made a lot more ships since then and which have gone up in build quality progressively. You can send me a PM if you need to get sorted out with a ship for an FM.

What are you talking about? Edit: Ah I see: It's not really important I think if you use the already excisting TDM installation (but starting TDM with the Linux executable) from the Windows drive. If you install TDM (from Linux) on the persistent storage space, it might be slow. But maybe it's not really so bad.

That's right, but it would have to be better than a virtual Linux for testing scripts go.Test and test are 2 different words for Linux

Well, let's explore this a bit. How can this be solved? Currently, creeping overrides running (like you said). Here are a couple issues or considerations: What about players who want to keep the fine control of toggling each one independently? Perhaps some players want to go from creeping to running. At the moment, the code is written in such a way (due to its Doom 3 history) that toggling creep can set the toggled run state, but toggling run cannot set the toggled creep state. The toggle creep key can set the toggled run state to walk but only once. If the player presses the toggle run key again, it will toggle without regard to the toggled creep state. Fixing this would require a lot of code rewriting. Brainstorming: It almost sounds like increase and decrease speed keys are desired. Run key to go from creep to walk and from walk to run. Creep key to go from run to walk and from walk to creep. If you're curious to give this a try, here's a Linux test build that matches beta212-05 (rev 16950-10635) with the following change: The toggle creep key sets the toggled run state to walk but only once. If the player presses the toggle run key again, it will toggle without regard to the toggled creep state. https://drive.google.com/file/d/1osTCQRf7LQ5wPvhGl2uRU4NcFnJPEu9_/view?usp=sharing

Yeah, I don't know what to say. Rev 10383 works fine and 10384 does not. It is always reproducible for me, meaning that every time I try to reproduce it, I can reproduce it. After some more testing, I found that r_multiSamples set at 2 or 4 has the glitch most often at that viewpos. When set to 8 or 16, it is still possible but less likely. Setting r_fboResolution 2 made no difference. If com_maxFPS is set to something lower, such as 30, the glitched frames display for a longer period of time. Yeah, I also wonder if it driver dependent or GPU dependent. I discovered the glitch while using graphics drivers Mesa 22.0.5, so I updated my OS and graphics drivers to Mesa 23.3.2 today as a test, and the problem is still there. It's strange that rev 10384 exposed this problem. My machine specs and settings: Linux, Ubuntu 22.04 AMD Ryzen 9 5900X AMD Radeon RX 6700 XT (Mesa 22.0.5 & Mesa 23.3.2 both exhibit the glitch) com_fixedTic 1 com_maxFPS 60 Anti-Aliasing 2x (r_multiSamples 2) The video I shared shows the viewpos. Even at the same viewpos, the glitched frame will pop in and out. I've only seen this glitch happen in this single room in Accountant 1. If I move around the room at that viewpos, I can find other view positions that also expose the glitch. Here's another viewpos for Anti-Aliasing 4x, 8x, and 16x. It requires moving the mouse slightly to get into the exact viewpos to expose the glitch. (1.7 -166.4 0.0) is not precise enough. -1460.29 1425.48 172.25 1.7 -166.4 0.0 Glitched frame (Shows the curtain texture, covering most of the frame. Also, a hint of the red carpet texture?): Good frame (Same viewpos and Anti-Aliasing settings, when the glitched frame disappeared for a moment.): (Before and after rev 10384) I wonder if this might also be related to: (Before and after rev 10384) Also, sometimes on the loading screen with Anti-Aliasing enabled, I get a glitched background, which does not show with Anti-Aliasing disabled. See left side of screenshot: I don't know if the last two examples (distorted first frame on launch & loading screen distorted background) are related, but I thought I'd mention them just in case it helps track down the issue.

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

I have recently installed this on Linux Mint 20.3 and I am getting performance issues, namely the frame rate is choppy. It's still playable, but it is uncomfortable to play for too long because of the choppy visuals. I have tried lowering the graphical settings but no matter how high or low I set them I get the same result. I also have the official nvidia driver installed. On the same machine I have a Windows 7 install and it runs perfectly smooth there, so I know it's not an issue of inadequate hardware. I know I could just boot into Windows and play it but I would have preferred if I could play it on Linux since that is my main OS on this PC. Any ideas?

What you can do is: Download Manjaro Linux XFCE edition. (XFCE edition has best performance) Put it on usb-stick (usb 3.0 minimum, otherwise too slow). You can use Rufus for this. Boot from it, using the Proprietary drivers option in boot menu. Inside Manjaro linux, go to your Windows drive to the folder with your tdm installation. Start thedarkmod.x64 (NOT TheDarkModx64.exe) I tested this and it loads pretty fast.

I've personally had no issues running Linux Mint in dual boot with Windows 10. Just need to disable secure boot when installing Linux then upgrade to the latest kernel and grub2 then re-enable secure boot. My Windows has its own SSD so your experience may vary.

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

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.

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

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.

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.

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.

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

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.

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.

You can try with Wine (some have had success, though there may be visual issues or other imperfections). Oops, I guess you can't use Wine because TDM on Linux will be an actual native version, which AL presumably would not be able to interact with. Other than that, sorry, I'm pretty tied to Windows for AL as a whole. A separate app for TDM only would be much easier to port to Linux, no need for the Windows-only RichTextBox and no need to interact with Wine from the Linux side programmatically either. One could use the Avalonia UI framework for that, I would think. Maybe I'll give it a shot sometime, but for now I'll polish up TDM support on current AL.

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.

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.