Chapter 5-3 giving some texture bug

[RiasatSalminSami]

Everything was working fine until I killed "It" and went to next location. First my Red 9 bugged out, followed by merchant and then krauser. I'll try to recreate the bug and see if it repeats.

Fortunately I was recording the game when it happened, so I'm gonna link the whole footage here [Video is still uploading, will take a while to finish uploading and process]: https://youtu.be/5T5-X2nCt7k

Time stamp: 27:27

Actually just realized the bug appeared immediately after the cutscene showing death of "it", the first gun to bug out was Striker after I equipped it.

[nipkownix]

Hmm, weird issue. I imagine it doesn't happen without the HD project installed, right? Might be something wrong with that cutscene you mentioned. Will ask Albert if he knows anything about it.

[RiasatSalminSami]

Hmm, weird issue. I imagine it doesn't happen without the HD project installed, right? Might be something wrong with that cutscene you mentioned. Will ask Albert if he knows anything about it.

I tried to recreate it but it's not happening anymore.

Does that mean it's some kind of memory leak? It's worth mentioning, I've been playing the game for like 2+ hours at that point.

Tried to recreate twice now, but didn't appear anymore.

[Mister-Curious]

This is a memory buffer issue that happens from time to time. I know its not the cutscene models because all cutscenes use the pl00 and pl08 udas for the body. If those aren't loading their textures it's a memory issue. Make you sure you have the 4B patch applied and that you have enough video memory

[RiasatSalminSami]

This is a memory buffer issue that happens from time to time. I know its not the cutscene models because all cutscenes use the pl00 and pl08 udas for the body. If those aren't loading their textures it's a memory issue. Make you sure you have the 4B patch applied and that you have enough video memory

Patch was already applied and the mod was installed by following all the step thoroughly.

I got 6 GB vram, maybe it's not enough.

[Mister-Curious]

I have a RTX 2070 super with 8gb ram and lots of system ram and even then I get this issue from time to time, but this is usually with very taxing custom rooms I have made.

[RiasatSalminSami]

I have a RTX 2070 super with 8gb ram and lots of system ram and even then I get this issue from time to time, but this is usually with very taxing custom rooms I have made.

I realzied the cutscene models were loading just fine after watching my own footage again.

So this is not a memory issue then? I wasn't playing on custom rooms.

[emoose]

Hmm, since it only happened after inventory was opened I wonder if it's related to RaiseInventoryAlloc.. the pG+0x3C stuff we had problems with was part of code that'd load in fonts after all.

(I think font textures are loaded with GXLoadImagePack stuff which seems seperate to all the heap crap though, so maybe it's not actually related to it...)

If anyone can find a way to force this to happen please let us know, could be interesting to look at it with PIX graphics debugger (even a custom mod that it happens with could be good to check with)

E: also it seems the game has a maximum of 256 textures loaded at once, maybe it's possible that something went over that limit & caused other textures to be overwritten. Not sure if that 256 limit could be extended or not though... will try looking into it some more.

[emoose]

More font texture weirdness (don't know what version re4_tweaks user had though), interestingly they were also at Chapter 5-3 too: https://www.re4hd.com/?page_id=9317#comment-197937 / https://drive.google.com/file/d/1ePh31TfOIgVbGB-GCcn3ygPaWLmR7qS5/view

Wonder if something in that chapter might be messing up the heap enough for font texture stuff not to get alloced properly.

Also that reminds me, maybe we should display re4_tweaks version on the UI somewhere, so users are more likely to mention it.

[nipkownix]

Huh. Weird one.

Here's what albert said about the images in the OP:

Leon's face is now stored in the 07000000.pack file which is loaded at the beginning of the game and always in memory. From the look of the pictures, it seems a bug related to textures called from Em folder models (all textures stored inside 000000xx.pack, 010000xx.pack and 020000xx.pack files (enemies, characters and weapons ingame models))

It does look like the game simply stops loading these pack files at some point. If you don't know, the reason every texture turns into a font file is because that's what the game seems to consider a "default" texture (it is also inside 07000000.pack, which is always in memory). I remember having that show up when .pack and .lfs tools first became available and I decided to mess with textures for fun.

So yeah, I don't think it is anything related to our increased pG texture buffer.

(I think font textures are loaded with GXLoadImagePack stuff which seems seperate to all the heap crap though, so maybe it's not actually related to it...)

Raz0r's dll actually changes something related to GXLoadImagePack, but I don't remember what.

Also that reminds me, maybe we should display re4_tweaks version on the UI somewhere, so users are more likely to mention it.

True. I'll add it in the raw-input branch, since the logging there has the necessary stuff for it now.

[emoose]

Could be related to the 256 texture limit I saw, if you open the IDA 7.7 database and look at local types I added a GX_D3DState struct there, which has a member IDirect3DTexture9 *CurTexture_C[256]; Kinda looks like only 256 textures can be rendered each frame, who knows if that's actually being reached or not though.

Extending that would probably take some work, I think there's some other stuff in GX_D3DState that describe each texture too (eg. look at GXExt_GXTex_to_D3DTex)

Maybe will try looking into some way of displaying texture count on-screen, might be helpful for next time someone runs into it.

E: eh maybe not, looks like most scenes only fill ~6 slots of that array, doubt it'd reach 256. Maybe is an issue with the pack loading instead, will have to try looking at how it handles memory there.

E2: hm, looks like a lot of the texture loading code calls into OSPanic_nullsub when there's a problem, might be useful to hook that & print contents to console/log file.

(unfortunately 1.1.0 corrupt a lot of the error msgs though, I guess because they were in japanese and they compiled for chinese lang or something, OSPanic calls contain source file + line # though, so should still be possible to track it from those)

[Mister-Curious]

"... is because that's what the game seems to consider a "default" texture (it is also inside 07000000.pack, which is always in memory)." Actually the default texture (the black font texture is located in 0f000001.pack which is also always loaded into memory.

"Could be related to the 256 texture limit " I can say for sure that this happens without exceeding 256 textures, as I have a custom room that this issue used to happen in frequently (the issue of the handgun missing textures, and the muzzle fire missing textures).

I definitely think this one is a memory issue because I had the exact same problem (the issue of the handgun missing textures, and the muzzle fire missing textures) was fixed when I reduced the amount of water effects being drawn. I had over 20 instances of a water effect in a room (each using 60 textures), being loaded at once. The room was a bit unstable and after some troubleshooting I found that the issue was related to the water effect. What I did to reduce the load was to create an EAR triggerzone to only allow visible instances of the water effect to be drawn (visible to the player camera).

[emoose]

Yeah seems I was wrong about the 256 limit, not sure what that was for, maybe some kind of effect or something.

Found a more likely limit though, GXInitTexObj etc makes use of an array at 0x10C8008 to store info about each texture, each entry is 0x30 bytes, and array is 0x23280 bytes, leaving room for 0xBB8 / 3000 texture entries.

The uint32 at 0x10ECB84 seems to be number of total allocated textures, seems this only increases and never gets lowered in games lifetime (but I think game still reuses freed textures, at least it seems to scan for freed ones)

I've only gotten it up to ~0x270 but I guess it could go higher in some scenes, would be interesting to check that in chapter 5-3, my guess is corruption probably happens when that goes around/above 3000.

Might be possible to increase the buffer for that, seems to only have a couple usages at least.

E: tried area jumping across a bunch of maps, never got the counter above 0x2D7...

GXInitTexObj also seems to handle something to do with ImagePack files too, looks like there's a limit of 64 imagepacks being loaded at once, there's even a warning for when it goes above 0x3F: GXInitTexObj ERROR : Data of the image pack may have not been read id [% p]\n (E2: can't get imagepack count above 12 though :/ maybe issue is something else, like game choosing wrong texture instead or something like that...)

[nipkownix]

@Mister-Curious is there a chance you could provide us a test map that triggers this issue reliably?

[Mister-Curious]

@Mister-Curious is there a chance you could provide us a test map that triggers this issue reliably?

Yes I can have that ready for you tomorrow sometime. Shoot me your email.

[emoose]

@Mister-Curious not sure if you've sent to nipkow already, but could you mail me that level too? email is on profile page https://github.com/emoose

[Mister-Curious]

@emoose sent you an email.

[nipkownix]

Oh, sorry, I missed your message, @Mister-Curious. Never had this many issues in a repo before, :p

Here's my email: skidrowa@gmail.com

[emoose]

@Mister-Curious replied, my email likely got sent to spam folder though, maybe I need to look into switching email host...