Jump to content
The Dark Mod Forums

Search the Community

Showing results for tags 'engine'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General Discussion
    • News & Announcements
    • The Dark Mod
    • Fan Missions
    • Off-Topic
  • Feedback and Support
    • TDM Tech Support
    • DarkRadiant Feedback and Development
    • I want to Help
  • Editing and Design
    • TDM Editors Guild
    • Art Assets
    • Music & SFX

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 7 results

  1. I've recently posted this into another thread, but I thought I might as well make a thread about it. Regarding engine upgrading, I was wondering, it would perhaps be best to create a separate webpage dedicated to the TDM Engine, chiefly to document new features and updates that separate it from idtech4, but also to attract potential developers that can help improve it. Is there a github page for the code, or something like it?
  2. https://bugs.thedarkmod.com/view.php?id=5055 There seems to be an issue with shadow rendering in the engine: When enabling both Stencil Shadows and Soft Shadows, shadows get incorrectly mapped and are stretched across the screen in front of the camera. I have no issues when using Stencil Shadows without shadow softness, nor when using Map Shadows both with and without soft shadows. I'm running TDM 2.07 x64. My operating system is Linux openSUSE Tumbleweed x64. Kernel 5.2.14. Mesa 19.1.7 (amdgpu module). My video card is an AMD Radeon XFX R9 390. I attached two screenshots from the FM Full Moon Fever: The first shows stencil shadows without softness (normal results) and the second is stencil shadows with softness (corrupt shadows).
  3. Ok so we are having a lot of talk surrounding TDM's engine, and its amazing that we are having so much done in the way of improvements to it, lately. I thought it could be fun to have a (yet another) place where we as fans could post things we would like to see added to the game, more specifically to its mechanics. Just suggestions for things that we feel would reinforce the game's strengths and design choices. Obviously, its up to the team and coders to know where to best place the resources and what needs to be prioritised. But a man can dream... Having said that, lets start with something simple and easy... Physics overhaul Ok, maybe not an overhaul, but if theres one thing I always wanted to see improved in TDM (idtech4), before any graphical enhancement, was actually the physics. Not just the sort of fixing that has been taking place on specific points (like being able to KO guards with thrown or fallen objects, which was implemented back in the day). In my dream scenario, TDM would be going closer to a true "physics simulation" type of plataform (keeping gameplay needs at the front, of course). Why do I say that? The potential for a slow, deliberate stealth game in a trully responsive world are immense. Lets remember some of the possibilities to gameplay coming from great physics, as seen in Half Life 2 (I use it because its from the same generation as Doom3): (In the second video) The moment where the player accidentally pushes the pc monitor and it falls down (at 2:02) making a mess, or the whole section from 2:50 to around 4:50 are great examples of things that would be so fun to have in TDM with a more advanced physics system: - responsive chain reactions between objects, rewarding the use of moveables in maps because they can play a crucial role (you dont wanna accidentaly drop a bunch of bottles by bumping clumsily into the table holding them); - pushing objects into place to create obstacles and have their combined weight slow down enemies; - destructable geometry, based on their material (this is so amazing, as you can see in the first video with the wood structures - they seem to be true breakable shapes, organically reacting to impacts or pressure). - being able to throw or cause the movement of heavy bodies that take out enemies and damage other bodies upon impact, even objects with so much mass that they can crush anything on their path; HL2 is a prime example because they used physics masterfully to create all sorts of interesting interactions between the player and the storyline, like puzzles you had to solve using objects and force, or using physics to set traps and take people out, etc. Unfortunately, our engine, although I think many of the principles are there, seems a lot more limited overall. So I wonder how realistic it is for TDM to eventually improve its physics mechanics, either by enhancing doom3's own physics, or by implementing parts of external engines like Bullet or something. Im no expert and have absolutely no idea how hard any of this would be. But I do feel this could be something really interesting for future gameplay.
  4. I hope this isn't a useless thread, just thought it would be constructive to let everyone know about it. I was looking up some TDM related concerns, and accidentally stumbled across another fork of the idTech4 engine. It's called fhDOOM, and it seems to have a lot of neat graphical improvements over the stock engine. eXistence/fhDOOM There are definitely things in there that TDM could consider grabbing! Some important ones highlighted on their front page: Modern renderer based on OpenGL 3.3 core profile. Any up-to-date engine should have this as a norm.Parallax mapping. Not sure if we have this already... I only know the original engine had simple bump mapping.Soft shadows. A heavily desired and long awaited feature.Alpha textures affecting shadows. This allows light to shine through textured grates, which is a very beautiful improvement.Soft particles. This one we already have now however.An example of the old lighting system (ours) versus lighting with shadow mapping (fhDOOM): As the obstacle to new features is almost always finding someone willing to code them, discovering those improvements for our engine is a goldmine... since unless they conflict with any of our changes, I assume they should be easy to just plug into the code. Can any of this good stuff please be considered for inclusion in TDM's version of the engine?
  5. I recently saw a post about the functionality of the idTech 6 engine, which brought this suggestion to my attention. It's actually a simple and trivial improvement, although I can imagine people missing it and not thinking about its absence. Also keep in mind I don't know the lighting code of TDM, and everything I say is purely out of observation. Like most engines that use dynamic lighting, TDM tends to have considerable performance issues when a lot of lights are rendered at once. This is often because of shadows and possibly other calculations. A common way to prevent extra computation in the renderer is caching all lights, and only updating each one when necessary. Meaning either the light itself has moved, or something is moving in front of the light. If both the light and the geometry it affects are static, there is nothing to recalculate, which offers a significant performance boost. TDM has a serious problem here: Even if the engine already knows how to cache lights, every torch has a moving light source! If you look closely at a torch, you'll notice its shadows constantly bob around. While this makes sense aesthetically, it also means that light will be recalculated each frame... even if the torch is mounted on a wall and no physical object or NPC is currently moving within its radius. Since most maps use torches and have areas where characters don't walk in front of them, I see a notable performance improvement being lost here. My personal suggestion: First of all, does idTech 4 support light caching for static lights + geometry to begin with? If somehow the original engine didn't have that, I definitely think it should be patched in! Once that's solved, I believe moving light sources for flame based lights should be controlled by a cvar; If people are okay with the performance loss, they can enable that to get bobbing shadows... if not, disable to allow torch lights to be cached and improve overall FPS. An idea to compensate for the visual loss: Can't we use an animated light texture to simulate moving flames altogether, as well as pulsating brightness? The light bobbing looks pretty extreme anyway: In real life, candles have a smooth flame that casts a neat shadow, and shadows don't always move that chaotically even when it's a noisier flame like a campfire.
  6. I am trying to compile the latest SVN engine, on openSUSE Tumbleweed (via gcc 4.8). Compilation goes well until the end, when the process mysteriously fails for an unexplained reason. The only thing that seems to be printed is the name of the file and something called "Error 1". Anyone else running across this, and knows of a solution? Thanks. cm/CollisionModel_load.cpp: At global scope: cm/CollisionModel_load.cpp:42:13: warning: ‘versioned’ defined but not used [-Wunused-variable] static bool versioned = RegisterVersionedFile("$Id: CollisionModel_load.cpp 6551 2015-10-15 18:48:23Z stevel $"); ^ In file included from include/boost/filesystem/path_traits.hpp:23:0, from include/boost/filesystem/path.hpp:25, from include/boost/filesystem.hpp:16, from framework/../idlib/../idlib/Image.h:29, from framework/../idlib/../idlib/Lib.h:230, from framework/../idlib/precompiled.h:106, from framework/precompiled_engine.h:28: include/boost/system/error_code.hpp:221:36: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable] static const error_category & posix_category = generic_category(); ^ include/boost/system/error_code.hpp:222:36: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable] static const error_category & errno_ecat = generic_category(); ^ include/boost/system/error_code.hpp:223:36: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable] static const error_category & native_ecat = system_category(); ^ scons: *** [build/release/core/cm/CollisionModel_load.o] Error 1 scons: building terminated because of errors.
  7. I am wondering why can't entities limit to be expanded beyond 8192 entities ? (I am sure it's plenty, but still)
×
×
  • Create New...