Implement fix for Skyscraper Scamper Act 1 (Day) building drawing incorrectly

UnleashedRecomp/patches/misc_patches.cpp

@@ -193,29 +193,3 @@ PPC_FUNC(sub_824EE620)
 
     ctx.r3.u32 = PersistentStorageManager::ShouldDisplayDLCMessage(true);
 }
-
-// This is a constructor for some struct that constructed inside CTownManContext::CTownManContext()
-// and within the calls contained in CTownManBase::ProcMsgSetTownManRetryTimeTable().
-// 
-// Within the constructor of the CTownManContext, the second member of this struct is initialized to -1
-// after this call happens inside CTownManContext::CTownManContext() at pretty much the very of that function call.
-//
-// This initialization of the member variable is however not executed when this constructor for the struct
-// is called from someplace else in the game's code, as such it remains with unitialized data for that field.
-//
-// Ensuring that this member variable is initialized to 0 anytime this constructor is called fixes an issue with
-// Tails not disappearing when giving you the camera after Rooftop Run Act 1 (Night). This setting of it to 0 won't
-// break the behaviour created by the call to it from CTownManContext::CTownManContext() as that itself sets it to -1 later on.
-// It only affects other instance of the call.
-//
-// NOTE: ctx.r3.u32 + 0 is also unitialized by this constructor, however both instances of this function being called
-// initialized the said variable later on before being used.
-// 
-// NOTE: ctx.r3.u32 + 20 is also unitialized, however I could not find any uses for this. Since this is already
-// quite a big change due to the amount of NPCs in the game, I would rather not touch this unless an issue is found.
-PPC_FUNC_IMPL(__imp__sub_8297C630);
-PPC_FUNC(sub_8297C630)
-{
-    PPC_STORE_U32(ctx.r3.u32 + 4, 0);
-    __imp__sub_8297C630(ctx, base);
-}

UnleashedRecomp/patches/video_patches.cpp

@@ -141,3 +141,26 @@ PPC_FUNC(sub_82E38650)
 
     __imp__sub_82E38650(ctx, base);
 }
+
+// Part of the building right after exiting the tunnel after the drift turn after the first checkpoint
+// is placed on an transparent mesh slot. This somehow works. Except on high-performance Windows machines,
+// hinting at the fact that its related to some scheduler issue with the asset loading.
+// We can fix it by detecting the asset runtime, and combining the opaque and transparent mesh slots by
+// using the name offset field on the mesh group as an additional value in the array and shifting the
+// opaque mesh slot's offset back by one and then correcting the offset table for this change.
+
+// Hedgehog::Mirage::CTerrainModelData::Make
+PPC_FUNC_IMPL(__imp__sub_82E39618);
+PPC_FUNC(sub_82E39618)
+{
+    if (ctx.r5.u32 == 0xA470 && XXH3_64bits(base + ctx.r4.u32, ctx.r5.u32) == 0x8474C14C113626D2)
+    {
+        PPC_STORE_U32(ctx.r4.u32 + 0x28, 7);
+        PPC_STORE_U32(ctx.r4.u32 + 0x2C, 0x38);
+        PPC_STORE_U32(ctx.r4.u32 + 0x30, 0);
+        PPC_STORE_U32(ctx.r4.u32 + 0x50, 0x88C4);
+        PPC_STORE_U32(ctx.r4.u32 + 0xA438, 0x38);
+    }
+
+    __imp__sub_82E39618(ctx, base);
+}