Search the Community

I just stumbled upon this thread (because I saw that snatcher is involved which is always exciting ) but I wonder why we would want a lamp that can not be used at the same time as a weapon? This brings back memories of the stupid Doom 3 flashlight which did the same thing just for jumpscares. So if you really want to show a visible lamp, can't the player hold it in his left hand while the right one is still free at least for blackjack, sword and to pick up items?

In order to better discuss performance, please look into this article: https://wiki.thedarkmod.com/index.php?title=Tracy:_timeline_profiler#Gameplay Perhaps inspect some Tracy records too. The game consists of four main parts, most of them run in parallel: game modelling renderer frontend renderer backend GPU Let's suppose n-th part consumes Tn milliseconds of time on some interval, then the interval takes min(t1 + t2, t3, t4) of time in total. Usually either p.1 + p.2 or p.4 are bottleneck. If you try doing less updates, you cannot make renderer backend and GPU faster: it still has to render all the stuff every frames. Except for something like reusing shadow maps between frames, which is not implemented yet. You can make game modelling faster if some entities skip thinking. The most time-consuming entities are AIs, and this kind of optimization is applied to them since the very beginning of TDM, known as "interleaded thinking optimization" (Doom 3 had similar but stronger "dormancy" concept). If an AI is behind closed doors and far from player, then he thinks rarely, e.g. 3 times per second. You can use cv_ai_opt_forceopt cvar to experiment with it. It took much effort to make this work reliably, but without it TDM should be very slow on anything but small levels. And this optimization caused some headache later, for instance it caused distant AIs to randomly die with uncapped and low FPS. All the other entities think every frame, as far as I know. Some entities are known to be dangerous to think rarely: that's mostly physics-related things like ropes and ragdolls. Another thing is that many entities spend negligible time in their Think methods, and most entities don't think at all (only "active" entities think, see listActiveEntities command). Speaking of renderer frontend, you can update entities less often. Then you can reduce time on understanding which areas entities belong to, and on generating interactions (that's the main part I think). However, there are parts of frontend which are view-dependent, so they need to run every frame. You can experiment with cvar r_skipUpdates. As far as I understand, it disables all updates of render entities/lights from game code. The game modelling still runs, guards still move around, see you, speak, chase you, and kill you. But renderer displays the obsolete state of the world from the moment when you set the cvar.

Apparently it's opt-in though. I don't have a problem with features like this, as long as they are opt-in and clearly explained. Recently I got a smart TV and I was stunned and amazed how non-hostile, straightforward and user-friendly the setup process was. It didn't try to force me to do anything I don't want to do, like connect to the Internet. Instead of saying "let's connect to the Internet", it said "Would you like to connect to the Internet?". And there was a "no" button, not a "maybe later" button. Also it boots up to the HDMI port extremely quickly; even faster than my ten year old dumb TV. It takes 3 seconds at most. So yeah, there's doom and gloom in my mind about TVs eventually not letting you use the inputs until you opt in to all the tracking, and perhaps coming with a cellular radio for spying that you can't disable, but we are fortunately not there yet. https://www.consumerreports.org/electronics/privacy/how-to-turn-off-smart-tv-snooping-features-a4840102036/

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.