FOVAdditional causes crash on first level?

[emoose]

Hi, seems re4_tweaks causes a crash for me on the first level for some reason, I wrote some more about it on the NM page: https://www.nexusmods.com/residentevil4/mods/101?tab=posts

Some reason I keep running into a crash right at the start of the game though, after starting new game skip through the intro movies, then when you spawn in the map just run forward, always seems to crash for me just before reaching the signpost :/

Strange thing is I'm sure I got passed the signpost before, with the exact same settings etc. Not sure what could have changed that made it start crashing...

If I rename winmm.dll to disable it the crashing goes away, so seems it's probably something that re4_tweaks added in. (should probably mention, I'm using the re4hd pack too)

E: ah might be caused by FOVAdditional, I was using 20 for the above, but changing it to 0 seems to get rid of the crashing.
Unfortunately the FOV changes is mostly what I used re4_tweaks for though... I could use a save to skip past the area that crashes & use 20 with that, but not sure if there's still a chance of something else also crashing later on due to it :/

EDIT: seems it's not just the first level, have had crashes loading from saves too :/ changing back to FOVAdditional = 0 stops the crashes from happening though.

[nipkownix]

Hey, sorry for the delay. I've been quite busy lately.

So, FOVAdditional causes the crash? I must say I expected crashes with everything but this option, lol

I suspect this only happens if you have the re4hd pack installed. I will download the latest version and investigate.

[emoose]

For what it's worth, the FOV fix in FlawlessWidescreen's ResidentEvil4.lua seems to work fine, had a quick look at it and seems to work pretty much the same as yours too, exact same signature searched for/ASM hook/etc, not really sure why that works without issue.

(the ResidentEvil4.lua included with it is outdated though, I had to use the updated one on PCGW: https://community.pcgamingwiki.com/files/file/1112-resident-evil-4-ultimate-hd-edition-flawless-widescreen-fov-patch/)

[nipkownix]

the ResidentEvil4.lua included with it is outdated though, I had to use the updated one on PCGW

I'm actually the one who patched that ResidentEvil4.lua script. I've been fighting with the FOV in this game for a long time :p

Well, after some testing, this issue is also happening with Flawless Widescreen (at least for me). Maybe your FOV wasn't set high enough to trigger the crash? Here's my settings:

and seems to work pretty much the same as yours too, exact same signature searched for/ASM hook/etc

Yeah, the FOV stuff was the very first feature I added to re4_tweaks, and I based it of the code on ResidentEvil4.lua, as it seemed to work just fine. But apparently it crashes due to some changes in the HD project.

Not sure how to proceed. The issue might not even be present in the latest develpment version of the HD project.

I'll look for an alternative way of changing the FOV for now, seems like it is my best bet.

[emoose]

In case it helps at all, it seems PS2 version included debug symbols inside it, I've had some luck using symbols for other machines to find stuff in PC builds before (by searching for similar strings/constants etc), maybe could come in useful: https://twitter.com/diwidog/status/1188626209560596480?s=19

IIRC there was a debug build posted on Steam for a short while too, don't think it had symbols though sadly, but maybe some of the debug options it includes might help (https://docs.google.com/spreadsheets/d/1NVc5G6sXbRKbYsridRW0pTdTf0GunDHL5E5neLsugoM/edit#gid=0 lists the manifest ID etc for it)

E: also seems you're right about Flawless Widescreen causing crashes too, setting to 40 made the first level crash at least, luckily 10-20 seems fine which is what I've been using, wonder why that seems fine with FW but not this mod though...

E2: been doing some digging comparing the PC & PS2 versions, seems the function you patch for FOV is known as "move__12CameraSmoothR12CAMERA_POINT", aka CameraSmooth::move(CameraSmooth* thisptr, CAMERA_POINT a2), which gets called by "Move__13CameraControl" / CameraControl::Move, haven't found the func that crashes yet though.

Seems the FOV is stored in a CAMERA_POINT struct, +0x1C into the struct for PC, +0x24 for PS2, haven't found where that's loaded in yet though, there is some stuff that seems to load camera data inside CameraControl::RoomDataRead & CameraControl::CoreDataRead, but haven't seen anything actually writing the FOV value there... if that does handle reading in FOV it'd probably be a good candidate for hooking though.

E: welp, kinda found where FOV is originally read from, at 0x59C401 [esi + 0x28] is the FOV value, only needs to be changed once and then all future frames will use it, but even with that the game still crashes at that signpost...

Haven't been able to find much about the crash, seems to be inside a memcpy operation, but VS says memcpy is being called by d3d9.dll somehow, and stack seems to have some d3d-related things inside it... not really sure why d3d9 would call into the games version of memcpy for anything though, weird.

[emoose]

Aha think I found a fix for it, the game allocs some vertex buffers at 0x939DD0 (and around 0x94BC10), but seems they're too small, making IDirect3DVertexBuffer9::Lock return E_FAIL when the game tries locking an offset past the size of one of those buffers (it fails at ~0x5bbe40, while one of the buffers is size 0x5B8D80)

Just hex edited the EXE to double the buffer sizes, and with that the crashes seem to be gone.

I'll update this with a list of file offsets in a sec, if you want to add this to your mod feel free btw :)

5392A1 (939EA1): 80 1A 06 00 -> 00 35 0C 00 (400000 -> 800000)
539276 (939E76): 00 09 3D 00 -> 00 12 7A 00 (4000000 -> 8000000)
53924C (939E4C): 80 84 1E 00 -> 00 09 3D 00 (2000000 -> 4000000)
539222 (939E22): 80 8D 5B 00 -> 00 1B B7 00 (6000000 -> 12000000)
5391F8 (939DF8): 80 8D 5B 00 -> 00 1B B7 00 (6000000 -> 12000000)

54B2B3 (94BEB3): 80 1A 06 00 -> 00 35 0C 00 (400000 -> 800000)
54B25C (94BE5C): 80 84 1E 00 -> 00 09 3D 00 (2000000 -> 4000000)
54B289 (94BE89): 00 09 3D 00 -> 00 12 7A 00 (4000000 -> 8000000)
54B22F (94BE2F): 80 8D 5B 00 -> 00 1B B7 00 (6000000 -> 12000000)
54B011 (94BC11): 80 8D 5B 00 -> 00 1B B7 00 (6000000 -> 12000000)

The addrs are file offset & memory addr, I'm not completely sure the addrs are correct though, some reason I've been working with 2 different EXE versions somehow, I think the addrs should be for the latest steam ver, but maybe my steam copy was downgraded by a mod or something, not sure.
(you should just be able to search for them as AOBs and replace them, they're the only instances of those bytes across both versions afaik, all have 0x68 (byte) just before them too)

I haven't tested this out too much yet, but looks like the start-level crash is fixed with it at least :)

[nipkownix]

Awesome finds, emoose! I've been looking at buffer sizes in the game for a couple of months, but never got any progress. I never imagined changing the FOV would trigger a crash in this case, though.

E: welp, kinda found where FOV is originally read from, at 0x59C401 [esi + 0x28] is the FOV value, only needs to be changed once and then all future frames will use it, but even with that the game still crashes at that signpost...

Yeah, I also did some digging earlier today and came across the same thing. I re-implemented the hooking and still had the same crashes too. But the new implementation is cleaner, so I'll probably use it in future versions.

Thank you for the offsets! I'll definitely take a look at those soon. Perhaps we can even solve another two issues regarding buffers: video size and the "ss_pzzl.dat" file size.

I've been trying to help albert from the RE 4 HD project with making the game load high-res videos. I've solved one issue, which was the image being zoomed in if the resolution was higher than the default. That was relatively simple. The second issue is the real kicker: the game crashes if the resolution is too high. After some digging using IDA, the game crashes because it is trying to read/write to memory that doesn't exist. It is most likely a buffer being too small, but I'm honestly not sure about how I'd manipulate it.

Same thing happens for a file called "ss_pzzl.dat".

Do you think you could try to find anything about these issues? I can upload some test files that trigger the crashes if you need.

[emoose]

Heh I actually first started looking into RE4 to try getting high-res vids to work, didn't have much luck with it though, but then again I didn't actually have any files to test with, so never really got that far into it. If you can up those files I could try taking a look.

BTW do you have any idea if it's an issue with the game itself or could it be something codec related? I think RE4 uses an older Criware codec, had some luck getting Nier Automata to work with high-res vids before but that was using the newer Criware stuff, not sure if older Criware had much support for HD+ videos...

Is ss_pzzl.dat a file changed by HD project? Maybe because other files are made larger it's not leaving enough room for that to be loaded or something... If they're using Criwares filesystem stuff I think there's some values that can be tweaked there though, maybe can figure something out there.

[nipkownix]

Heh I actually first started looking into RE4 to try getting high-res vids to work, didn't have much luck with it though, but then again I didn't actually have any files to test with, so never really got that far into it. If you can up those files I could try taking a look.

Ah, nice!

Here's a 1920x1080 test video:

https://files.catbox.moe/vr5jqo.zip

Replace the one inside \Resident Evil 4\BIO4\movie
The game will try to display this video as soon as you start a new game.

BTW do you have any idea if it's an issue with the game itself or could it be something codec related? I think RE4 uses an older Criware codec, had some luck getting Nier Automata to work with high-res vids before but that was using the newer Criware stuff, not sure if older Criware had much support for HD+ videos...

I'm confident it is related to buffer size/memory allocation. Not only I observed that using IDA, but this issue was also fixed before by someone else: https://www.nexusmods.com/residentevil4/mods/32?tab=description

raz0r's "dll companion" fixes both crashes by "Allocating more RAM for certain stuff". Not sure what he means by that, but it works.
bro, why not provide the source code? :/

Although it does fix the issue, it also.. adds some nagging screens and a bunch of other things that don't suit the HD project.

Is ss_pzzl.dat a file changed by HD project?

It is. That file contains the weapon models for the items you see in the inventory screen, when pressing TAB in-game. Right now it has some hardcoded size limit and crashes. In other words, if albert tries to make actual high-poly replacements for these models, the game crashes.

Here's a test ss_pzzl.dat he sent me some time ago:

https://files.catbox.moe/j982z1.zip

Replace the one in BIO4\SS\eng\
Delete ss_pzzl.dat.lfs if it exists.

The game should crash if you press TAB.

Thanks for taking a look at these!

[emoose]

Found a way to stop it crashing with that sfd, just needed to increase memory pool sizes so that memset wouldn't error, luckily the code they use for allocating those pools is pretty simple.

  const int MemPoolMoviesVanillaSize = 0x580000;
  const int MemPoolMoviesNewSize = MemPoolMoviesVanillaSize * 10; // 1080p needs ~0x1600000 bytes
  const int Mem2VanillaSize = 0x3700000;
  const int Mem2NewSize = Mem2VanillaSize + MemPoolMoviesNewSize;

  // Increase movie memory pool size
  SafeWrite(GameAddress + 0x25636F, MemPoolMoviesNewSize);

  // Increase mem2 root pool size to include expanded movie pool
  SafeWrite(GameAddress + 0x574829, Mem2NewSize);
  SafeWrite(GameAddress + 0x57485F, Mem2NewSize);
  SafeWrite(GameAddress + 0x574887, Mem2NewSize);
  SafeWrite(GameAddress + 0x5748B1, Mem2NewSize);

Doesn't really seem to be playing properly though, might be skipping the movie entirely, or maybe its something to do with the resolution zoom-in you mentioned. I did notice PS2 ver has a func called ScreenReSize, seems to be at 0x657AE7 on PC, gets used to resize movies to 512x448 I think.

There's also cSofdec::SetupResolution at 0x97F63C, looks like the params to it are taken from the SFD header, and then it scales it against the params used for ScreenReSize, not sure though.

(E: eh, that code might not be that safe atm since lots of things access the memory pool offsets directly, moving the MemPoolMovies offset to the end of the pool and extending it from there should be fine though, but would need hooking instead of patching...)

E2: something a little safer, using MinHook to hook the mem pool creation func & overwrite the offset for movie pool after it's finished

const int MemPoolMoviesVanillaSize = 0x580000;
const int MemPoolMoviesNewSize = MemPoolMoviesVanillaSize * 10;
const int Mem2VanillaSize = 0x3700000;
const int Mem2NewSize = Mem2VanillaSize + MemPoolMoviesNewSize;
const int MemPoolMoviesOffset = Mem2VanillaSize;

typedef void(*MemCreatePools_Fn)();
MemCreatePools_Fn MemCreatePools_Orig;
void MemCreatePools_Hook()
{
  MemCreatePools_Orig();

  uintptr_t* g_MemPoolMovie = (uintptr_t*)(GameAddress + 0x865CAC);
  uintptr_t* g_Mem2Root = (uintptr_t*)(GameAddress + 0xE6E5F4);
  *g_MemPoolMovie = *g_Mem2Root + MemPoolMoviesOffset; // new movie mem pool starts at end of vanilla mem2
}

void Plugin_Attach()
{
  GameModule = GetModuleHandleA(nullptr);
  GameAddress = reinterpret_cast<uintptr_t>(GameModule);

  MH_Initialize();
  
  // Increase offset for movie memory pool
  // (previously I did try just patching the size at 0x25636F, but a bunch of things elsewhere in the game are hardcoded to specific offsets)
  // (relocating movie memory to end of Mem2 pool seemed the safest idea, but requires some kind of hook to work)
  MH_CreateHook((LPVOID)(GameAddress + 0x2562B0), MemCreatePools_Hook, (LPVOID*)&MemCreatePools_Orig);
  
  // Increase mem2 root pool size to include expanded movie pool
  SafeWrite(GameAddress + 0x574829, Mem2NewSize);
  SafeWrite(GameAddress + 0x57485F, Mem2NewSize);
  SafeWrite(GameAddress + 0x574887, Mem2NewSize);
  SafeWrite(GameAddress + 0x5748B1, Mem2NewSize);
  
  MH_EnableHook(MH_ALL_HOOKS);
}

Also seems the issue with ss_pzzl is memory-pool related too, there's a few places where the addr that it gets loaded into is hardcoded, but not too hard to patch those to end of mem-pool & extend it, like for the movies.

Unfortunately it still won't work with this though, seems there's some code at 0x768113 that copies the ss_pzzl-pool into another buffer, managed to find where that buffer gets created (mem_alloc call at 0x71981B), but changing the size there results in the mem_alloc call failing, returning 0 as addr :/
mem_alloc is part of the heap-memory system the game uses, seems separate to the memory-pool stuff, haven't found a way to resize it yet...

As a test I tried hooking mem_alloc / mem_free to call malloc/free instead, and that actually seemed to work :o, the inventory opens up fine with that ss_pzzl at least, but closing the inventory results in some OOB read, not sure if that's an issue with the alloc/free hooks or if it's the ss_pzzl itself though. (E: seems to do the same with original ss_pzzl)

[nipkownix]

Amazing finds!

Here's a test build with the new fov hook and the fixed vertex buffers:
winmm.zip

It appears to be working nicely, at least in the first stage. I'll do a more in-depth test later.

I couldn't get your MinHook based code to work here, though. Might be because I'm not familiar with MinHook at all, or maybe the addresses are wrong? What is your game version, by the way? Mine is 1.0.6

Edit: yeah, the addresses are not making sense with my version. Maybe your exe is ver 1.1.0?

[emoose]

Ah yeah those addrs were for 1.1.0, probably wouldn't be too hard to port to 1.0.6 though, or maybe make it use sig-scans instead, was 1.0.6 the last version before 1.1.0? Maybe I can use depotdownloader to grab it.

(btw any reason for sticking to 1.0.6? there mods that only work on that maybe? or is that just better in some way?)

E: here's the minhook version for 1.0.6:

const int MemPoolMoviesVanillaSize = 0x580000;
const int MemPoolMoviesNewSize = MemPoolMoviesVanillaSize * 10;
const int Mem2VanillaSize = 0x3700000;
const int Mem2NewSize = Mem2VanillaSize + MemPoolMoviesNewSize;
const int MemPoolMoviesOffset = Mem2VanillaSize;

typedef void(*SystemMemInit_Fn)(); // SystemMemInit name from PS2 symbols
SystemMemInit_Fn SystemMemInit_Orig;
void SystemMemInit_Hook()
{
  SystemMemInit_Orig();

  uintptr_t* g_MemPoolMovie = (uintptr_t*)(GameAddress + 0x86242C);
  uintptr_t* g_Mem2Root = (uintptr_t*)(GameAddress + 0xE6AD74);
  *g_MemPoolMovie = *g_Mem2Root + MemPoolMoviesOffset; // new movie mem pool starts at end of vanilla mem2
}

void Plugin_Attach()
{
  GameModule = GetModuleHandleA(nullptr);
  GameAddress = reinterpret_cast<uintptr_t>(GameModule);

  MH_Initialize();
  
  // Increase offset for movie memory pool
  // (previously I did try just patching the size at 0x25636F, but a bunch of things elsewhere in the game are hardcoded to specific offsets)
  // (relocating movie memory to end of Mem2 pool seemed the safest idea, but requires some kind of hook to work)
  MH_CreateHook((LPVOID)(GameAddress + 0x256140), SystemMemInit_Hook, (LPVOID*)&SystemMemInit_Orig);
  
  // Increase mem2 root pool size to include expanded movie pool
  SafeWrite(GameAddress + 0x573499, Mem2NewSize);
  SafeWrite(GameAddress + 0x5734CF, Mem2NewSize);
  SafeWrite(GameAddress + 0x5734F7, Mem2NewSize);
  SafeWrite(GameAddress + 0x573521, Mem2NewSize);
  
  MH_EnableHook(MH_ALL_HOOKS);
}

[nipkownix]

was 1.0.6 the last version before 1.1.0?

Yeah, it was.

(btw any reason for sticking to 1.0.6? there mods that only work on that maybe? or is that just better in some way?)

None that I know of, but my game actually won't "update" to ver 1.1.0 for some reason. Some people never got this update, myself included. Seems like new owners of the game receive ver 1.1.0, while original owners are stuck with ver 1.0.6. (I bought this port on release)

E: here's the minhook version for 1.0.6:

Awesome! I'll test this later tonight.

probably wouldn't be too hard to port to 1.0.6 though

Yeah, I figured as much. Thank you for doing it. I would have done it myself, but I'm honestly a begginner at reverse engineering. I'm not sure how you even found those addresses :p I'd appreciate any tips, or maybe just the process you used to reach these addresses

[emoose]

Huh strange, I was just looking at steamdb to find 1.0.6's manifest and seems they set the depots up really weirdly: https://steamdb.info/app/254700/depots/

The "Resident Evil 4 WW" depot has 1.0.6 as latest manifest, while 1.1.0 seems to be inside the "resident evil 4 / biohazard 4 Test Depot" depot. I guess game downloads the WW 1.0.6 version first, then overwrites with the 1.1.0 test depot contents.

Looks like they messed up the permissions on that test depot though, if you open the WW depot it says 18 steam subscriptions have access to it, while test depot only has 9, guess that's why some don't get access to it...

Doubt they'll ever fix that now though, but who knows, maybe if enough people posted on steam forums they'd take notice.

I'm not sure how you even found those addresses :p I'd appreciate any tips, or maybe just the process you used to reach these addresses

For the movies it was mostly just debugging the game with VS, and when the crash happens stepping back through the stack trace.
With this it was memset causing an exception, going to caller function in stack trace brought me to 0x6CD34D (1.1.0) which from PS2 symbols is cSofdec::startApp, and you can see a pointer is passed to memset, (g_MemPoolMovie in my code above), looking at xrefs for that pointer brought me to the function that set up the mem pools etc, and then just had to figure out a way to resize them :)

Really this was kinda lucky, could have been a lot worse if they were making heavy use of C++ stuff. The ss_pzzl stuff seems like it's pretty similar too, but seems the heap stuff might be relying on mem1 pool instead of the mem2 one that this resizes, haven't had any luck getting mem1 to resize properly yet though.

E: seems there might be some more things that access g_MemPoolMovie that need to be resized, if you check xrefs for it there's stuff that tries writing to +0x420000 etc, could be why movie doesn't play properly, hm.. (E: no luck changing those sadly...)

E2: just got around to trying your new winmm build too, seems to work fine, good job!
Was the console window something newly added though? A few times the game seemed to leave fullscreen and switch to the console window for some reason, don't think that happened with 1.5 once, but can't remember if 1.5 also had that console window or not.
Maybe would be best to make the console window something that has to be enabled from config INI, as a debug console setting or something.

E3: also about high-res movies, do you know if a low-res version of that movie you linked does work in the game fine? It seems like RE4 on PS2 includes different movie codecs to the PC version, I'm wondering if maybe the high-res movie you linked could be using a codec that PC version doesn't actually support... that'd explain why it just gets skipped over at least.
The linked sfd seems to use a much different format to the games too, and an sfdview.exe tool I found refuses to open it (also doesn't open the original sfds neither, but those give an error message at least, the linked one just says it's an invalid sfd)

[emoose]

Huh I think the issue is with the sfd actually, I tried muxing my own 1080p sfd using sfdmux.exe instead and it seems to play fine after patching, although was zoomed in, do you know what to patch to fix that?

I think a cleaner version of the movie pool patches could be made too, crimw seems to accept memory region from anywhere, so can probably just patch it to use a malloc()'d block based on what mwPlyCalcWorkCprmSfd returns (which is what the game should have been doing in the first place...)

E: looks like the malloc idea works, using this sfd that's based on a random 1080p clip I found:
opening_pal.zip

Using 1.1.0 offsets:

typedef int(__cdecl* mwPlyCalcWorkCprmSfd_Fn)(/* MwsfdCrePrm * */ void* cprm);
mwPlyCalcWorkCprmSfd_Fn mwPlyCalcWorkCprmSfd_Orig;
int __cdecl mwPlyCalcWorkCprmSfd_Hook(/* MwsfdCrePrm * */ void* cprm)
{
  int workarea_size = mwPlyCalcWorkCprmSfd_Orig(cprm);

  // alloc a workarea based on what mwPlyCalcWorkCprmSfd_Orig returned - allows high-res videos to play without crashing :)
  void* workarea = malloc(workarea_size);

  void** g_MemPoolMovie = (void**)(GameAddress + 0x865CAC);
  *g_MemPoolMovie = workarea;

  return workarea_size;
}

typedef void(__fastcall* cSofdec__startApp_Fn)(void* thisptr);
cSofdec__startApp_Fn cSofdec__startApp_Orig;

void __fastcall cSofdec__startApp_Hook(void* thisptr)
{
  // Backup original g_MemPoolMovie value
  // we need to change this so that cSofdec::startApp uses our own memory block instead of the hardcoded (& incorrectly-sized) memory pool
  // a few other things rely on g_MemPoolMovie value though, so it needs to be changed back after this func has ran
  // unfortunately we dont know the size of g_MemPoolMovie until mwPlyCalcWorkCprmSfd is called though (during cSofdec::startApp)
  // so a mwPlyCalcWorkCprmSfd hook is used to handle allocating & updating g_MemPoolMovie, while cSofdec::startApp hook is just used to backup/restore original addr

  void** g_MemPoolMovie = (void**)(GameAddress + 0x865CAC);
  void* g_MemPoolMovie_Original = *g_MemPoolMovie;

  cSofdec__startApp_Orig(thisptr);

  *g_MemPoolMovie = g_MemPoolMovie_Original;
}

typedef void(__fastcall* cSofdec__finishMovie_Fn)(uint8_t* thisptr);
cSofdec__finishMovie_Fn cSofdec__finishMovie_Orig;
void __fastcall cSofdec__finishMovie_Hook(uint8_t* thisptr)
{
  cSofdec__finishMovie_Orig(thisptr);

  // cleanup the workarea we allocated
  // ps2 version seems to memset(0) the workarea here, PC version doesn't do this though
  // should mean it's safe to assume the workarea isn't being used anymore, so we can free it here
  void* workarea = *(void**)(thisptr + 0x130);
  free(workarea);
}

void Plugin_Attach()
{
  GameModule = GetModuleHandleA(nullptr);
  GameAddress = reinterpret_cast<uintptr_t>(GameModule);

  MH_Initialize();

  MH_CreateHook((LPVOID)(GameAddress + 0x611F80), mwPlyCalcWorkCprmSfd_Hook, (LPVOID*)&mwPlyCalcWorkCprmSfd_Orig);
  MH_CreateHook((LPVOID)(GameAddress + 0x2CD2F0), cSofdec__startApp_Hook, (LPVOID*)&cSofdec__startApp_Orig);
  MH_CreateHook((LPVOID)(GameAddress + 0x2CDC60), cSofdec__finishMovie_Hook, (LPVOID*)&cSofdec__finishMovie_Orig);

  MH_EnableHook(MH_ALL_HOOKS);
}

For 1.0.6 change

• the two g_MemPoolMovie offsets to 0x86242C
• mwPlyCalcWorkCprmSfd offset to 0x610AD0
• cSofdec__startApp offset to 0x2CCBB0
• cSofdec__finishMovie offset to 0x2CD500

IMO this is better than needing to juggle the mem2 addrs/sizes around, just need to find signatures for the 3 funcs, and a signature to find the offset for g_MemPoolMovie - I'd guess the code that sets up the addrs for that could probably be sig-scanned and offset grabbed from it.

The mwPlyCalcWorkCprmSfd & cSofdec::startApp hooks could probably be changed to 1 hook if you used an asm patch somewhere (after the mwPlyCalcWorkCprmSfd call I guess), I've never been that good at writing x86 asm though :P

E: the issue with the original SFD you linked might be something bitrate related, I noticed changing max_bps passed to crimw seemed to get something to display on screen, only for a second though... changing that required cri to use 512MB+ for the workarea though, so kinda wasteful.
The sfd I linked is pretty low bitrate which might be why it works... will need to try making a higher bitrate version
(E: higher bitrate seemed to work fine, maybe it was a codec thing?)

[nipkownix]

Was the console window something newly added though? A few times the game seemed to leave fullscreen and switch to the console window for some reason, don't think that happened with 1.5 once, but can't remember if 1.5 also had that console window or not.
Maybe would be best to make the console window something that has to be enabled from config INI, as a debug console setting or something.

The console window is there just for debugging purposes, really. I use it to watch some variables when needed. I forgot to disable it in the build I uploaded.

also about high-res movies, do you know if a low-res version of that movie you linked does work in the game fine? It seems like RE4 on PS2 includes different movie codecs to the PC version, I'm wondering if maybe the high-res movie you linked could be using a codec that PC version doesn't actually support... that'd explain why it just gets skipped over at least.
The linked sfd seems to use a much different format to the games too, and an sfdview.exe tool I found refuses to open it (also doesn't open the original sfds neither, but those give an error message at least, the linked one just says it's an invalid sfd)

You know, that is strange. The sfd I linked is actually working fine here with both the older and newer codes you posted. I'm in the process of integrating it into re4_tweaks and using sig scans, but it works here. Maaaybe I uplodaded the wrong .sfd before? Can you try using the new encode?

https://files.catbox.moe/9rbfum.zip

I love the new approach for the video fix, btw! Congrats!

also the raz0r companion you linked doesn't seem to fix movies or ss_pzzl for me, I noticed it says "4GB patched: NO, limited functionality" on the top right though, even though I did 4GB patch it, dunno why it can't detect that properly, maybe it's not patching properly because of that?
Do you have a bio4.exe that it does work with, and makes ss_pzzl etc work?

Here's my exe:

bio4.zip

Huh I think the issue is with the sfd actually, I tried muxing my own 1080p sfd using sfdmux.exe instead and it seems to play fine after patching, although was zoomed in, do you know what to patch to fix that?

The function at bio4+2CC6E0 (0102C6E0) v1.0.6 seems to be loading some parameters to set the display dimension of the video (-256 and 256). I previsously hooked the fld asm instructions there and changed the value to match whatever was needed for 1080p videos.
Not sure how that value is calculated though, so I just went with trial and error. Edit: nvm, I'm dumb. It is actually quite simple.