Search the Community

I don't recall a system for noise masking. It sounds like it'd be a good idea, but when you get into the details you realize it'd be complicated to implement. It's not only noise that that goes into it, I think. E.g., a high register can cut through even a loud but low register rumble. And it's not like the .wav file even has data on the register of what it's playing. So either you have to add meta-data (which is insane), or you have to have a system to literally check pitch on the .wav data and paramaterize it in time to know when it's going to cut through what other parameters from other sounds. For that matter, it doesn't even have the data on the loudness either, so you'd have to get that off the file too and time the peaks with the "simultaneous" moment at arbitrary places in every other sound file correctly. And then position is going to matter independently for each AI. So it's not like you can have one computation that works the same for all AI. You'd have to compute the masking level for each one, and then you get into the expense you're mentioning. I know there was a long discussion about it in the internal forums, and probably on the public subforums too, but it's been so long ago now I can't even remember the gist of them. Anyway the main issue is I don't know if you'll find a champion that wants to work on it. But if you're really curious to see how it might work, you could always try your hand at coding & implementing it. Nothing beats a good demo to test an idea in action. And there's no better way to learn how to code than a little project like that. I always encourage people to try to implement an idea they have, whether or not it may be a good idea, just because it shows the power of an open source game. We fans can try anything we want and see if it works!

I'm using the version from kcghost. I just tested and I can't see any difference inside the inventory. On the stats itself it doesn't show the different loot types (still seen in the inventory), but instead gives more info on stealth score. Edit: I see Dragofer made an updated version of his script. I have to check that out. Edit2: That version works: https://forums.thedarkmod.com/applications/core/interface/file/attachment.php?id=21272&key=02755164a3bed10498683771fe9a0453

Right, so there is this one weird qwerk of classic Thief. If you beat an AI to death with the blackjack (I know, I know, but sometimes it's fun to fight this way because it's more of a challenge than using the sword) as though Thief was a Quake clone, the guard will scream and begin to drop. But if you quickly wack him again, he will pop up and play the "knocked out" sound, and then collapse again. So basically you killed him, and *then* you knocked him out! The natural question at this point, is how the stats would reflect such an oddity. I guess there is only one way to find out, but the problem is, there's usually more than one dead guard on the map when I play. Especially on Thieve's Guild. I go straight-up Doom on that one, and use the corpses to trace my steps around the confusing layout. The classic Thief guards aren't great fighters; they are especially vulnerable to circle strafing and lots of pelting. You can even get them completely turned around and facing the other direction! As long as you're in a relatively open space you can own them by doing this quite easily. This strategy will not work on TDM guards. Try this with them and you are the one that gets owned. lol

Old topic: SteveL had most of the basics of func_occluder \ antiportal working but was struggling with shadow handling and a few related concerns. Quake mappers would probably love the feature since they've already been using it for years but it's hard to say whether TDM \ Doom 3 folks will really want to add another optimization workflow? Admittedly func_occluder seems to be easier to visualize than portal closure behavior so it might not be as error prone.

Occlusion culling is not as easy as it looks. For instance, if you simply check entity's bbox against individual brushes, then most of the entities behind walls would pass the check because no individual brush covers a whole entity completely. Also, there are dozens thousand brushes on large maps, you cannot iterate through them naively. On the other hand, this is close to the concept of "antiportals". That's when mapper puts an "antiportal", ensuring that everything behind it is occluded, and the engine takes it into account whenever it works with portals. But this requires work from mapper, and I don't think it would provide much help. To get serious benefits, you need to recognize the whole wall consisting of many brushes as a single inpenetrable surface, at which point you necessarily have something really complicated. I thought about doing Umbra-like occlusion culling on brushes (with automatic portals and conservative rasterization inside), but I realized it's ton of work. There is always something else to do. By the way, the recent change is not about what player does not see, it's about what light don't see/hit. Just rendering a surface is very cheap because of depth prepass, but light interactions are costly with all the textures, soft shadows, etc. Realizing that you don't need light interaction on something you see is quite beneficial. The problem with original Doom 3 engine is that it basically lights up all objects within light volume. With the exception of static shadow-casting lights, portals are just ignored! I have expanded usage of portals to dynamic lights. It might sound funny, but there is still some room for improvement in this area...

I looked but didn't see this video posted in these forums. It's pretty cool.

I've never actually seen the insides of an elevator but from what I know about electronics in similar settings from a few friends who did some work in the field, my guess is that it's an ARM system on a chip and it's quite possible that it runs Linux. And it's highly likely that it's separated from a chip that's taking care of the actual elevator movement, so you probably couldn't use the buttons for input. The reason for this being that ARM SoCs able to run linux are really not that expensive nowadays, whereas developing custom systems outputting graphics with a cheaper weaker chip has a large upfront cost. And if you're using a universal OS like Linux, you can keep the software side the same if the ARM chip you're using goes out of production and you need to switch to a new one. If these assumptions are true, running Doom on it would be easy provided there's some input method.

It wasn't a "sacrifice", it was a deliberate decision. People wanted the game to be as close as possible to the original, including pixelated graphics. If you ask me, the former version based on the Unity engine looked and felt better. But, hey... I guess I'm not the right person to judge that, as I never played the original, and always found that the art style of System Shock 2 is much better anyway. This also illustrates the issue with community funded games: Too many cooks spoil the broth. In game design, you need freedom, not thousands of people who want you to do this and this and that. Just take a look at the Steam forums and see how all those wimps complain again about everything. Hopeless.

Of course you're free to not play it if you don't want to. Personally, I would have given it the Resident Evil remake treatment; with graphics that would absolutely blow the mind, new areas to explore, surprises and changes for people who think they already know the game just because they played the original one five times over, etc. What we got here is not really that, and yeah, that's disappointing. But I don't think these people were working with a big budget. Also I like the way Doom 3 fleshed out the story and the environments, with those little videos playing on the wall which were there to explain the purpose of each location. I would have also done something similar to that in this remake; because it makes the game world feel more "real" and "lived in". Of course most people went into Doom 3 just wanting another action-packed Doom experience with minimal story or none at all, but I feel that it would have been more appreciated here.

guess they used DooM as the OS in the movie with the killing elevator -> you need to be atleast as old as me to know the one hehe.

So giving it none of those tags, but making the AI invisible, silent, non-solid, and on a team neutral to everyone would not work? Oh well, it was a horrible inelegant idea anyway.

What I understood is that the idea of TDM was born from that it was unclear if T3 would get a level editor at the time. Source: https://web.archive.org/web/20050218173856/http://evilavatar.com/forums/showthread.php?t=268

A more interesting question: Could an elevator inside TDM run Doom? Although I rather play System Shock.

This one is really essential: https://www.ttlg.com/forums/showthread.php?t=138607 Should work fine with the GOG version.

Just imagine all the time and effort people spend to run Doom on pregnancy tests would flow into something useful.

Doom min sys specs =some kind of screen, some keys and a shoebox

Its a matter of time and willingness. Doom can run several devices. Music theme on old floppy drivers and printers.

And what kind of computer is inside them, anyway? Is it some 8-bit thing, or something more advanced like an ARM architecture? The place I visited recently had an elevator with five full color LCD screens; one on every floor, and one in the elevator itself. I don't imagine an 8-bit computer driving them all at the same time... Note that it is presumably the computer's job to determine if the elevator is overloaded with too much weight, whether the doors are fully closed or not, etc.

https://www.ttlg.com/forums/showthread.php?t=152224 There is a new mapping contest over on TTLG for the Thief: Deadly Shadows 20th Anniversary and the organizers were kind enough to include The Dark Mod along with all of the Thief games as an options for making a mission to submit as an entry. The deadline is a year from yesterday and the rules are pretty open. I recommend going to the original thread for the details but I will summarize here: Rules: - The mission(s) can be for Thief 1, Thief 2, Deadly Shadows or The Dark Mod. - Collaborations are allowed. - Contestants can use any custom resource they want, though TDM cannot use the Deadly Shadows resource pack. - Contestants can submit more than one mission. - Contestants can enter anonymously. - The mission(s) can be of any size. Using prefabs is allowed but the idea is this is a new mission and starting from an abandoned map or importing large areas from other maps is not allowed. Naturally this is on the honor system as we have no way of validating. Mission themes and contents: There is no requirement from a theme or story viewpoint, however contestants might consider that many players may expect or prefer missions to be celebratory of Thief: Deadly Shadows in this respect: castles, manors, museums, ruins inhabited by Pagans and the like, with a balance of magic versus technology. This is entirely up to the authors, though, to follow or not - it is just mentioned here as an FYI and, while individual voters may of course choose to vote higher or lower based on this on their own, it will not be a criteria used explicitly in voting or scoring. Deadline: May 25th, 2024 at 23:59 Pacific Time. See the TTLG thread for details on submissions and the voting process. Provided I can make the deadline I hope to participate. It would be nice to see the entire community do something together, and expressing our complicated relationship with this divisive game seems as good a pretext as any.

Interesting article: Lightmaps in Doom 3 Engine: A Hybrid Approach To Real-Time Lighting tutorial - Mod DB

Looking back, I like this game better out of the two. I mean I can see why some people wouldn't like it; that shadow ninja can quickly end your game in a second even if you have 200HP with his one special move, at least on the harder difficulties. But I like the weapons, environment, sound and music more in this game than that of Duke3d. This game was short, but then they gave us two (high quality!) extra free episodes, so that is more than forgiven. Also, Shadow Warrior as a franchise was not ran into the ground like it's peer, and frankly, so many other classic games have been. I'm impressed that they're still making Shadow Warrior games, because I don't think this original game was a big seller. I wouldn't be at all surprised if Shadow Warrior's peer outsold it by two or three times. Duke3d was so popular and successful that it got the "port this to everything" treatment, like Doom did. It's fascinating how Shadow Warrior, a more obscure game, managed to turn around and become more successful as a franchise later.

OH!!! You have FPS set to Capped under the Advanced Menu eh? Doom 3's old capped FPS mode is "not great". Try setting it to Uncapped then set Max FPS to 60. ( Both under the advanced video options ) Normally this only helps on Linux but perhaps Windows 11 has the same problem.

That is slightly less than 4k but imo is still a really a high rez, specially for this engine, that is ~7.3 million pixels that the engine has to calculate/shade, per pixel 60 times or more, every second! also why MSAA (multisampling anti-alising) can be very expensive on this engine, it increases pixel count. So like nbohr1more said, if you have it on, lower it or better disable MSAA, at that rez IMO you don't need it anyway and it has no effect on geometry faces/surfaces, only on geometry edges and if you really want AA, also like nbohr1more said, force a post process one (FXAA or better if possible TAA) using the Nvidia driver. You can also try to lower the rendering scale and increase the sharpening filter to counter balance the loss of definition in the video options menu. About the CPU the fact you have low CPU utilization and high GPU utilization, shows you are getting GPU bound in this case, so increasing thread count in the game console, I don't think will help but try it. Btw sorry if you already know this but if you don't, at lest may explain to you why this "old" game, is so heavy even for your modern very expensive GPU, this game uses a modified Doom 3 engine, with better support for multicore CPU's and other modern stuff making it way faster than original Doom 3 engine, but is still using the old forward render and unlike more modern renders like deferred render or forward+, that can render hundreds of (non shadow casting) dynamic lights, before getting slow, a old forward render like of Doom3/TDM, can get really slow with a relatively low number of dynamic lights in a scene, worse if they all cast shadows, and on this game all lights are fully dynamic and in many missions most of them cast shadows, real time shadows, there's no light baking of any kind.

Personally I really don't know if that is available or not but that does sound too a specific guard behavior, so perhaps is not defined? If is possible to have that? Yes, if is not available already, unfortunately there's no other way but code it into the guard AI, in c++ or script yourself, if you know how to code.... Btw the civilian AI does have "fear" and runs away from danger, is that AI type really entirely separate from the guard AI, or the guard behavior is just "dormant" on the civilian AI and vice versa? If all AI's are done through the same AI system then perhaps is just a matter of turning some stuff on or off. If they are totally separate AI's, they are still so similar in parts that perhaps so you could adapt/transfer the civilian fear behavior into the guard AI for specific types of danger. But all of this requires coding. Sorry for not being more helpful than this, I really don't know much about TDM or even Doom 3 AI stuff.

Yeh that is also how Doom 3 weapons were done, but perhaps this can be worked around? Next to weaponDepthHack there's also a modelDepthhack bool I assume for every other model, perhaps that just needs to be put in the model def file or enabled by a spawn argument? I really don't know, or if that spawnarg even exists, if not then is something to put in the roadmap.