nbohr1more

@stgatilov Not sure but it seems that this inline is supposed to return the float for the axis? Shouldn't it be: ID_INLINE float idCircCone::Transform( const idMat3 &rotation ) { axis = rotation * axis; } ? That said, no issues compiling here with GCC 11. Any chance you would be willing to install that?

I'm guessing it will work just fine. OpenGL 4.6 compliant and performance roughly equivalent to Geforce GT 730

Can you try a less verbose compile string such as: cmake -DCMAKE_BUILD_TYPE="Release" .. -DGAME_DIR=/home/user/darkmod -DCMAKE_C_COMPILER=gcc-10 -DCMAKE_CXX_COMPILER=g++-10 https://wiki.thedarkmod.com/index.php?title=The_Dark_Mod_-_Compilation_Guide ?

Hmm... Pretty hacky, but I wonder if you could use something like this? float tdm_version_val = sys.getTDMVersion(); if ( tdm_version_val > 2.11 ) { string tempvalue = removeFrobPeers ; tempvalue(entity peer) ; } ;

Hmm Licensee.h appears to have these defined ( from svn ) : #define GAME_NAME "The Dark Mod" // appears on window titles and errors // greebo: Defines the darkmod release version #define TDM_VERSION_MAJOR 2 #define TDM_VERSION_MINOR 12 #define GAME_API_VERSION TDM_VERSION_MAJOR * 100 + TDM_VERSION_MINOR // e.g. 210 #define ENGINE_VERSION "TDM 2.12" // printed in console https://github.com/stgatilov/darkmod_src/blob/40db9596fcbf4fa3da42b3d89be0bd785620d154/framework/Licensee.h Does calling sys.getTDMVersion() without any define return the correct value? I am guessing if you wanna use this in a script you just: float tdm_version_val = sys.getTDMVersion(); if ( tdm_version_val < 2.11 ) { something } ;

I fixed two spelling mistakes and one conceptual mistake ( body vs bounty ) then packed the mission and added it to the mission database. Thank you!

I wonder if this new "FovoTec" thing: https://www.pcgamer.com/first-person-shooters-have-been-getting-perspective-wrong-all-along/ is just a Conformal perspective design being sold as something new? Anyone better than I at interpreting the study paper: https://psyarxiv.com/7xack/ ?

I spent way too long searching for this. I cannot find the thread but we had a long discussion about large vs small missions and I think the final tally was that most players and map authors preferred missions that were nearly as large or larger than the original Thief missions such as Baffords. TDM was partly a reaction to the smaller missions in Thief: Deadly Shadows and the hope was that we would eventually be able to offer missions that looked as good but were larger than TDS. Now we have some truly monster sized missions so the need to constantly create big mission might be excessive?

Looks like the only place we use longjmp is for jpeg loading. @stgatilov I recall you updated Libjpg in SVN recently, perhaps a new Dev Build will resolve this one?

Great list but I would imagine that the original Thief Series games and their Fan Mission collections are typically known quantities for TDM players. I have heard that TDM is sometimes a "gateway drug" that entices people to try the original Thief games but I have never heard of a long-time TDM player who has "no awareness at all" about the games that inspired the creation of TDM. If you are gonna suggest anything from the original Thief series games, it might be better to mention fan missions that have resemblance to TDM preferred aesthetics such as missions made by Skacky, Purah, Sperry, DrK, Spoonman, etc

I should have posted this link but my previous reply was posted from my phone: https://wiki.thedarkmod.com/index.php?title=Modular_Building#Modular_Building_Technique

Yes, this is possible but there are a few things that make it a little impractical. 1) Models do not seal the void so you need BSP brushes behind or inside models to properly seal a map. As I recall, there are doom 3 and quake map exporters that can export your initial block-out geometry as standard brushes so you could do both modeling and brushwork in blender. You’d just have to do it in phases 2) Visportal placement is crucial to performance so you will need to ensure you blender models are cut at portal boundaries so that you can setup brushes and visportals at choke points to prevent rendering outside the player view area 3) model geometry is often too complex for the physics engine. You will need to make invisible clip models or clip brushes that use a more simplified structure to ensure AI pathing and overall collision physics perform well. 4) Models need to be split at light boundaries. If a single light touches a model the engine will do light geometry calculation for the whole model. If enough lights hit a large model it can severely impact performance. Brushes will auto-split on light boundaries but often split in less optimal locations so it has become the convention to use func_static geometry to force brushes to split in the preferred locations 5) blender has no knowledge of specialty brushes like fog volumes, water, SEED auto dispersal etc So it’s possible to do the majority of mapping in blender but ultimately you will need to use Dark Radiant to do the finishing touches The current paradigm is to create modular content in blender and then assemble the modules together in Dark Radiant along with bsp caulking and vidportal placement

I was just thinking about my situation where "wife negotiation" would need to happen. I would probably just look for a used i7-5775C 65W 6MB cache ( 34% performance uplift in Single Core and 108% uplift in multi-core ) and ride it out until better AM5 options are affordable. Hard to say if that would workout since these seem to still command $200 prices in the used markets but it's probably cheaper than going for DDR4 + AM4 mobo + AM4 CPU in most cases.

20% is for the bottom of the Ryzen range. For $98 a Ryzen 5 5500 is over 70% faster and goes up to over 200% faster in some scenarios. There are probably a spectrum of inexpensive options between the Ryzen 3xxx and Ryzen 5 5500. https://www.cpubenchmark.net/cpu_value_available.html Still, finding an old workstation is not a bad way to go as a general practice but a lot of them are Intel based so the CPU upgrade path longevity might be more limited. At least the current gen Intel is socket compatible with the previous gen so you can get a last gen workstation and if there is a cutting edge low-end Intel CPU that beats the in-situ CPU in the workstation you can add that to the upgrade cost and probably recover a good chunk by selling the older CPU.

So a Ryzen 3 3200 is about 20% faster than that CPU. Anything reasonably inexpensive in the Ryzen 3xxx to 5xxx series would still be an upgrade for you.

Supposedly AM5 is going to support at least 3 cpu generations so if you are switching from Intel to AMD then that is probably the wiser move unless your Intel CPU is so old that a Zen 2 chip can beat it. If you do have a weaker Intel CPU and don’t mind waiting a long time then get an AM4 motherboard and a cheap Zen 1 or Zen 2 generation CPU then wait for the price of X3D AM4 CPUs to drop in a year or two. Basically just pretend it’s a few years ago and treat X3D as your final upgrade path. What Intel CPU do you currently run?

I believe that it was decided that the slow match should showcase our object manipulation features and is also designed to increase tension because real world use of a slow-match is sort of clumsy. Not sure if anyone currently on the project really cares about preserving this behavior and whether any missions rely on it since I don't recall any missions where lighting a fireplace (etc) put the player at risk beyond the risk of being illuminated anyway. This fiddly way of doing slow-match is probably something mappers like @Melan might prefer ( given his preference for other "retro" manipulations... eg. the big auto-unlock discussion for "The Rat's Triumphant" )?

The fix is in the mission database. Thank you Daft Mugi !

Re map_of.tga vs map_of_icon.tga ? The whole thing started because of an attempt to clear-up errors caused by a core file referencing a missing image. Some mission authors must have used this same path correctly so the attempt to fix this must have broken that and then the revert also broke something? @Dragofer ?

This should be updated in the mission database. If not, I will update the mission when I get a chance.

I'll upload the old Dungeon of Doom demo to Moddb so anyone interested can play around with it. I believe BloodRayne back in the Doom3world days also made a procedural map generator, I'll see if that is up anywhere where I can post it.

Make sure to use the version here: https://www.moddb.com/mods/the-dark-mod/addons/fresnel-mod-211-unofficial The most dramatic place to check this out is in the start area of the mission "Caduceus of St Alban". That said, any mission with large amounts of flat ambient lit surfaces that have the same texture over vast swaths of the scene will see dramatic improvement. The Vengeance for a Thief ( really, any Sir Taffsalot ) missions are particularly improved by this one.

I’ll bet it performs way better than stated in the article. When I saw the YouTube video it looked like they were using capped FPS which has horrible performance on Linux and even dips below 30 fps on the training mission with capable hardware. Uncap fps on the same setup and you have over 100fps everywhere in that same mission. Window works much better in capped mode but still has issues

Looks like it would be a good fit for "Swift Mazes":

The big improvement to load times was in 2.10. About a quarter of the time to load missions ( or lower ) compared to 2.09 ( which also had a few load time improvements). FPS improvement might be around 2x with Anti-Aliasing at 4x or higher. There were beta missions that saw a massive 150 to 200% improvement in performance but in both cases the authors fixed their performance issues through changes in map design or scripting. The project is now more resilient against some pathological performance issues if the map authors don't address them but no in-the-field map has any dramatic issues like these. We are future-proofed for bigger missions though. One mission "Scroll of Remembrance" still has very poor performance and the optimizations between 2.10 and 2.11 have had no effect. Likely the only way to address it is having the author or another team member examine visportals and other options to close off rendering.