Jump to content
The Dark Mod Forums

64-bit patch for the Dark Mod


NagaHuntress
 Share

Recommended Posts

idVec3 exposes its internal data through its ToFloatPtr() method. That gets passed to openGL a lot, so clearly the code wasn't designed with portability in mind. It's pretty much locked down to the original compiler architecture.

The game is locked down to single precision in the sense that it's locked down to 32-bits. With enough time and effort baked in floating point assumptions can be overcome. With a general conversion of floating point types to double, there will be a need to have it converting from double to float when the game engine passes data to the renderer.

 

The map size issue isn't a problem for TDM, where our biggest map extends less than 10k units from the origin.

Hmm... When I get time, I'll have to try the test map at an X,Y of 10k,10k and see if it glitches on me when the fixes I've done are disabled.

 

@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)

I suspect the fix is good enough for your needs, but it nags in my mind that this is not the correct solution and it merely patches over the symptoms of a real problem.

 

At the moment I can't say with confidence if the fixes I've made fixes a rare edge case exacerbated by large coordinates. Does the first fix, correct a bug or an edge case in the edge-edge collision detector? or is it just fixing up a false positives that end up pointing the wrong way? Have the changes simply changed a bug that manifests 1 in 100 times, to 1 in 100_000 times? If I can prove and rationalise it's behaviour in the domain of interest, I would be more confident in the fix, but I can't yet, so I'm worryworting over the issue.

 

That's the same article that I discussed with grayman and greebo when we were first discussing the bugs in our MSVC2013 port back in January. Except that the article's had more info added since then. It didn't have any mention of _controlfp_s or FLT_EVAL_METHOD at the time. I suspect those could fix our 2013 compile without needing us to rewrite any code. I don't know whether those switches can help us with our 64-bit build in MSVC -- the chart in the article suggests not -- so we might still have to bite the bullet and track down the sensitive lines of code. That'd be something I can at least help with... I don't know enough about compilers and OS environments to try to tackle it from the other end.

From looking at the compiler options for MSVS, it seems there isn't anything for disabling SSE or forcing the FPU when compiling to 64 bit. _controlfp() won't help much for a 64 bit build, as we can't get 80-bit floats due to the compiler not allowing x87 instructions. FLT_EVAL_METHOD (if it's supported) will only tell us it's compile time policy, which will probably be 0 (no promotion of intermediate types). It does look like making a 64 bit build under MSVC will require upgrading floating type and maths, either in controlled location or overall.

Link to comment
Share on other sites

Hmm... When I get time, I'll have to try the test map at an X,Y of 10k,10k and see if it glitches on me when the fixes I've done are disabled.

Well, I finally got some time to try the map moved to an X,Y of 10k,10k with fixes disabled, and I'm afraid to report that the player can get stuck on that ridge. The normal fix stops get the player from getting stuck as expected, but the player still stumbles (possibly less often, but that's very subjective at the moment). Adding the epsilon fix stops the stumbling (again, expected).

Link to comment
Share on other sites

Awesome progress!

 

I was wondering if you could test the performance between the 32bit and 64bit with my map: https://drive.google.com/file/d/0B89UMFFXqtD5eV9vUy1VV2Fkd2c

It's large and open and I'm curious to see if there's any benefits.

I always assumed I'd taste like boot leather.

 

Link to comment
Share on other sites

  • 1 year later...

After some more investigation, I discovered that AIs were going dormant. While dormant, they stand still and just run their animations, and, as I've seen before, they won't collapse if KOed or killed while dormant. AIs that were immune to this were those that were tagged as never dormant.

 

Investigating deeper into why they were being dormant, I found they were being set to dormant due to game thinking, that according to portal visibility, the AI and the player were in disconnected areas. From there the bug was found to be that the PVS wasn't allocate enough bytes for some optimisation tricks to work correctly.

 

After fixing that bug (see attached patch attachicon.giftdm--pvs-bit-correctness-fix.txt ) AIs no longer stood still, they could now see the player properly, and the sky box was being drawn correctly. So apparently the root cause of the remaining bugs were the same.

 

With that fix, my 64 bit version no longer has any known bugs. Soon I'll try to playing a good sized mission and see if I run into any more bugs.

 

 

The other attached patch ( attachicon.giftdm--dormant-ko-death-fix.txt ) makes it so that AIs will collapse if they're KOed or killed while dormant due to being in a disconnected area. I'm undecided as to the value of this patch, as it doesn't affect players in normal play and will only be of interest to scripts that remotely kill/KO AIs in disconnected areas.

Somehow the patch links aren't working. Does anyone have a copy?

 

Edit:

 

NVM. All set. :) Taaaki fixed the links.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


  • Recent Status Updates

    • STiFU

      We are taking our son on his very first holiday trip to see the sea for the first time. 🙂 Will be back in a week.
      · 0 replies
    • Gilkar

      When I was a young man my father was so ignorant I could hardly stand to have him around. As I grew older I was amazed at how much the old man had learned in such a short time.
      · 1 reply
    • jaxa

      RTX 3090 Super, RTX 3070 Ti 16 GB, RTX 2060 12 GB
      https://wccftech.com/nvidia-launching-rtx-3090-super-rtx-3070-ti-16gb-and-rtx-2060-12gb-by-january-2022/
      · 0 replies
    • duzenko

      CPU benchmark time - compiling DarkRadiant (2nd run)
      i5 8600K 6C/6T@4.4GHz DDR4 2x2133MHz 9MB cache
      Parallel builds: 1. 3:57 Parallel builds: 6 (default). 2:28 r5 1600AF 6C/12T@3.3GHz DDR4 1x2666MHz 16 MB cache, temp folder on HDD
      Parallel builds: 1. 5:05 Parallel builds: 4. 2:47 Parallel builds: 6. 2:55 Parallel builds: 12 (default). 2:57
      · 6 replies
    • nbohr1more

      Status updates are back so it is also a good time to return to contests!
      https://forums.thedarkmod.com/index.php?/topic/21095-christmas-connections-contest-2021
       
      · 0 replies
×
×
  • Create New...