Jump to content
The Dark Mod Forums

motorsep

Member
  • Posts

    884
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by motorsep

  1. You don't need to save / edit anything. DR would render scaled model from RAM. Physical copy stays as is. Same thing with rotations - models on HDD aren't rotated. They are only rotated in the viewports.
  2. We'll fix it in the engine. I am more concerned about the Editor.
  3. Models. And as you can see "important" note says rotation hack is not recommended. So I want to see if we can implement proper scaling.
  4. Would it be hard to implement scaling of func_statics in DR ? Besides visual uniform/non-uniform scaling, "scale" spawn arg should be created and modified on the func_static entity. This would allow building maps like in UE4 / Unity using kitbashing technique.
  5. We experienced interesting issue - on Win10 with AMD GPU, 32-bit build of our Doom 3 BFG derived engine crashes randomly, but 64-bit build works fine. Do you have similar issues with TDM ?
  6. Simply because Win7/8 is technically still WinXP. Windows 10 suppose to be redesigned, and when redesign happens, incompatibility happens. Whether it's flawed or not, we'll see next year, when MS fixes it up and updates it. Since it's the last version of Windows, I am sure they will keep refining it until it's better than Win 7.
  7. I assume T2 and T3 are Thief games from more than a decade ago ? How can you expect those games to just work on modern hardware and OS without devs updating them ? Plus, it's most likely related to video drivers, which doesn't have much to do with Win10 per se. Some Linux apps built with older libs and core won't run on current Linux builds. It's expected. Software needs to be adjusted and recompiled with/under new OS.
  8. Nah, I would like to be able to search references, have hints for functions/variables when hovering over them, peek definition, etc. Just like when you code in C++. Highlighting can work (somewhat) by default if you use C++ highlighting.
  9. There used to be this app for scripting: http://d3raptor.tripod.com/screenshots.html, but it's gone now. So having MSVC extension as IDE for DoomScript (and flexible/configurable enough to accommodate not only stock Doom 3, but any standalone game made with idTech 4, like TDM) would be awesome and quite useful!
  10. Has anyone ever tried making an extension for MSVC to allow coding in DoomScript inside MSVC, utilizing all it's power when it comes to search, highlights, hints, going to declarations and definition, etc. ? Is it possible?
  11. @NagaHuntress: Why is the fix you already implemented is not enough? It seems to be working fine (I am still testing large 120k x 120k terrain, but so far so good)
  12. I don't use patches a lot and I never made terrain with patches. However, player was getting stuck in the mesh made terrain. So I am guessing it's safe to say patches would have same issues as mesh/model.
  13. From what I understood, renderer uses same math classes as the rest of the code. If you would switch everything to doubles, there will be issues with rendering. But perhaps I misunderstood that.
  14. Would you only need to increase precision for collisions part of the code or for the entire codebase ?
  15. @NagaHuntress: I recall we tried a few years back (with Doom 3 engine) to move to double floats and performance penalty was very harsh (and I don't recall if it solved the issue of getting stuck) I wonder how CryEngine solves that issue with its massive outdoor levels. I've heard of a trick where player is always at 0 0 0 of the world, and the world moves around, unlike in conventional game engines, where the world is static, and player moves across the world.
  16. Yeah, but I meant interactively dragging bounds and having the volume to resize uniformly ?
  17. Is it possible to resize a light volume in DarkRadiant uniformly ? Thanks.
  18. Tested and indeed, it all works like a charm! Great job you've done, NagaHuntress, thank you! I am gonna see about trying to test AI/NPC and physics objects on that edge. Hopefully none will get stuck
  19. Is the direction of movement method in second (disabled in your patch) #elif block ? I also wonder if this fix affects non-player characters and AI (I haven't tested Doom 3 AI against that test case ).
  20. @NagaHuntress: Thanks a bunch - the fix works! The only issue, as you stated, it stuttering. I don't think it happens in FPS view (maybe I simply didn't notice as I didn't walk long enough on the edge), but it's very obvious in TPS view: (I used second method in the build I was testing). Hopefully you can figure this one out too I believe it was never an issue in Doom 3 simply because maps were smaller, and were mostly made of basic brushes - no slopes and such, just flat floors. I am thinking that since animations are played via script, the game still "thinks" player is on the ground and then momentarily in the air, and they again on the ground. So it switched anims crazy fast, and thus we see stuttering. I might be totally wrong, and even if I am not, I have no clue how to fix that.
  21. @NagaHuntress: Sorry, was at work. Here is the test case: https://drive.google.com/open?id=0BwE6dxM0O2PsQUNncWw0aGFuZms This is a video of me getting stuck:
  22. @NagaHuntress: I have a test case for collision issues (player gets stuck in the floor) in 64bit build (or 32bit compiled with /fp:strict). Would you care to give it a spin and potentially fix it ? (it was made for Doom 3, but I am sure it will run in TDM)
  23. May I ask what's the benefit of having 64bit build ? Besides obvious issues you already mentioned, you will have collision issues on both Linux and Windows builds. Plus you'd have to port all tools to 64bit platform (Linux has not tools, so it's a bit easier to deal with).
×
×
  • Create New...