Water Surface Rendering Fix

[cipherxof]

The rendering of water surfaces in cutscenes are broken when not playing in Letterbox mode. Reflections will either be misaligned or missing completely. This issue is most obvious in the cutscenes with the Sorrow as well as at the end of the game with Eva at the WiG.

For whatever reason, the game is using the wrong values for the reflection effect viewport while in fullscreen mode. Whether this is because the reflections are still being rendered in their letterbox aspect ratio or from something else, I'm not sure.

I've provided some examples below demonstrating the issue, along with the fixed version from this patch.

Broken	Fixed

Broken	Fixed

Broken	Fixed

[Lyall]

This looks good to me. My only suggestions would be to use less unique patterns so there's some resilience against game patches, also to add some logging upon successful hooking. Maybe something like this?

  if (eGameType == MgsGame::MGS3)
  {
      MH_STATUS status;

      uint8_t* MGS3_RenderWaterSurfaceScanResult = Memory::PatternScan(baseModule, "0F 57 ?? ?? ?? ?? ?? F3 0F ?? ?? ?? ?? ?? ?? E8 ?? ?? ?? ?? 48 8B ?? ?? ?? 48 89 ?? ?? ?? ?? ??");
      uintptr_t MGS3_RenderWaterSurfaceScanAddress = Memory::GetAbsolute((uintptr_t)MGS3_RenderWaterSurfaceScanResult + 0x10);
      if (MGS3_RenderWaterSurfaceScanResult && MGS3_RenderWaterSurfaceScanAddress)
      {
          status = Memory::HookFunction((uint8_t*)MGS3_RenderWaterSurfaceScanAddress, MGS3_RenderWaterSurface_Hook, (LPVOID*)&MGS3_RenderWaterSurface);

          if (status != MH_OK)
          {
              LOG_F(INFO, "MGS 3: Render Water Surface: Hook failed.");
          }
          else if (status == MH_OK)
          {
              LOG_F(INFO, "MGS 3: Render Water Surface: Hook successful. Hook address is 0x%" PRIxPTR, MGS3_RenderWaterSurfaceScanAddress);
          }
      }
      else
      {
          LOG_F(INFO, "MGS 3:  Render Water Surface: Pattern scan failed.");
      }

      uint8_t* MGS3_GetViewportCameraOffsetYScanResult = Memory::PatternScan(baseModule, "E8 ?? ?? ?? ?? F3 44 ?? ?? ?? E8 ?? ?? ?? ?? F3 44 ?? ?? ?? ?? ?? ?? 00 00");
      uintptr_t MGS3_GetViewportCameraOffsetYScanAddress = Memory::GetAbsolute((uintptr_t)MGS3_GetViewportCameraOffsetYScanResult + 0xB);
      if (MGS3_GetViewportCameraOffsetYScanResult && MGS3_GetViewportCameraOffsetYScanAddress)
      {
          status = Memory::HookFunction((uint8_t*)MGS3_GetViewportCameraOffsetYScanAddress, MGS3_GetViewportCameraOffsetY_Hook, (LPVOID*)&MGS3_GetViewportCameraOffsetY);

          if (status != MH_OK)
          {
              LOG_F(INFO, "MGS 3: Get Viewport Camera Offset: Hook failed.");
          }
          else if (status == MH_OK)
          {
              LOG_F(INFO, "MGS 3: Get Viewport Camera Offset: Hook successful. Hook address is 0x%" PRIxPTR, MGS3_GetViewportCameraOffsetYScanAddress);
          }
      }
      else
      {
          LOG_F(INFO, "MGS 3: Get Viewport Camera Offset: Pattern scan failed.");
      }
  }

[cipherxof]

Wouldn't it be more useful to report the address relative to baseModule? At the very least the base module address should be logged, because currently logging the absolute addresses doesn't allow us to actually check what is being patched in a disassembler.

[cipherxof]

I've updated with the requested changes as well as logging the module address.

[Lyall]

Wouldn't it be more useful to report the address relative to baseModule? At the very least the base module address should be logged, because currently logging the absolute addresses doesn't allow us to actually check what is being patched in a disassembler.

That's true, so should we add a log of the baseModule address during DetectGame? Then for the relative addresses on hooks have something like this?

  uintptr_t MGS3_RenderWaterSurfaceScanRelAddress = MGS3_RenderWaterSurfaceScanAddress - baseModuleAddr;
  LOG_F(INFO, "MGS 3: Render Water Surface: Address is %s+%x", sExeName.c_str(), MGS3_RenderWaterSurfaceScanRelAddress);

This would look like MGS 3: Render Water Surface: Address is METAL GEAR SOLID3.exe+5ac7c0 in the log.

[cipherxof]

Yes, that works. Although it may be worth doing a separate pass on all of the logs in another PR as to not muddy this one. For now, logging the base module address at least allows us to manually find the relative addresses.

[Lyall]

Yes, that works. Although it may be worth doing a separate pass on all of the logs in another PR as to not muddy this one. For now, logging the base module address at least allows us to manually find the relative addresses.

Sounds good to me. I'll merge this and put up a new release.

[emoose]

FYI in case it helps at all, you can disable the relocating with an EXE flag, steamstub would need to be removed first though: nipkownix/re4_tweaks#201 (comment)

Of course that doesn't help with user logs though, but can make debugging stuff a bit easier.