Directx9 fails to load all custom textures

[Vladabdf]

Only tried Birth by Sleep, but roughly half of the custom textures I have in place load in at any given time, immediately noticeable at the main menu. OpenGL loads all of them at all times, but I cannot use OpenGL because some cutscenes, as of version 1.3 (unsure which revision it started) crash the emulator and my display drivers.

If needed, specs: R9 390 8GB i7 4770K @4GHz 16GB DDR3 @1600MHz

[LunaMoo]

No idea about textures problem since I don't have that game, but before considering it a bug I would check if d3d9 simply doesn't end up with different hashes. In which case you would just need separate textures.ini with textures assigned to different hashes. In perfect world it should not be different, but since d3d9 is limited and buggy, it might end up different due to some effects affecting textures or even their unused parts.

As a general rule I would not recommend using that backend on any pc unless it's like 10 years old and can't support ogl at all.

With amd gpu's you're currently affected by this, for which we also have an issue opened #8698, but this has nothing to do with ppsspp. To make it work you'll have to use older drivers(pre-crimson), placing old OGL driver libraries inside ppsspp folder until amd releases their fixed driver is enough for a workaround, so you don't really need to affect whole system nor use the inferior backend.

[hrydgard]

If D3D does end up with different hashes, then that's a bug in itself.

[Vladabdf]

I made absolutely sure that no new hashes were being generated between D3D9 and OGL after playing a few minutes on one backend and switching to another. The only thing I noticed regarding the hashes is that sometimes multiples of the same texture would be dumped under different hashes in a single session. An example of this without fail would be the startup logos to Birth by Sleep, generating anywhere from two to five copies.

What's odd about the OGL issue though is I have been using the same drivers up until about five days ago when I updated from Crimson Edition 16.10.1 Optional WHQL to Crimson ReLive Edition 16.12.2. I also updated PPSSPP from 1.2.2 to 1.3 the same day though, so I had only assumed (foolishly it seems) it was an update to the emu instead of drivers. That said, reverting to the old drivers via clean install did not cure the issue, further leading me to believe it was an issue with the emulator. Apologies for the assumption here.

Edit: Image showing a handful of duplicate images with differing hashes

[LunaMoo]

As far as I tested today, out of the(unfortunately very few) games I replaced some textures in, there were no differences between the backends. Does the log show any error when it fails to replace textures? Also how you're replacing the textures, do you replace all duplicates using the optional textures.ini file? Looking on the screenshot for two textures with lots of small sprites which I'm guessing are UI related, you could just use wildcards for address part to hopefully replace them all. If you aren't doing it, that could just be the problem, maybe even just accidently and not trully related to backend. Other textures have both address and texture hash changing, so might be similar to this ~ potentially impossible to replace at least until someone finds a way to work around it.

If the game didn't crashed in ogl using ppsspp 1.2 and buggy crimson drivers, it's also possible the effect that now triggers the driver bug just wasn't working in this game earlier. Again you don't have to revert whole system drivers for it, just use ogl driver libraries ie posted by the user here just extract the two files atioglxx.dll and atio6axx.dll into ppsspp folder, you could also find those files from your own driver if you want to be extra safe, but it has to be pretty ancient pre-crimson driver like that 15.7.1 or 15.8 and alike, crimson drivers you used before/reverted to already had the bug and apparently as seen on AMD bugtracker it takes a while for them to push their fixes if they aren't affecting popular pc games.

Something I forgot about - I would also quickly check driver settings for "catalyst AI" also known as "surface format optimization" and if it's on, disable it, was causing some random crashes, probably not crashing driver through.

If it still crashes aka it's a new compatibility regression finding where the problem started could be useful. Should be easy on desktop with windows as well, as you can just use buildbot and continue checking builds in the middle between one that works and one which doesn't work to find exact commit or at least more reasonable range that started the problem. If the problem could be reproduced in some demo would be even better as everyone could check it without owning the game.:3

[Vladabdf]

As far as I'm aware (looked around, skimmed mostly), no log output was made, unless you're talking about the debug logger in which I turned that off. I also have not used the textures.ini file for texture replacement. I'll have to look into that to see if anything changes. You are also correct in that all those textures in the screenshot are UI elements. The issue you linked, however, is exactly the same that happens with me. Multiples of only a few select textures are created with a nasty garbled mess at the bottom, which is actually my guess as to why the textures may not be loading properly. To be more clear about the issue, OpenGL loads textures fine for the most part, however when the game loads to a new location, it generates some of the same textures (character sprites being a prime example) with the mess at the bottom very slightly different, which I can only assume would be the reason why OGL doesn't load them reliably at all times. Most of the time it does, but sometimes not.

I also tried the very same libraries you linked and moved to the ppsspp folder, to which nothing changed. Same crash at the same spot with the same effect. I also turned off "surface format optimization" the moment I installed my driver, so no worries there.

I'll get around to trying various builds (and demos) soon and update here what I come up with. Thanks again!

Edit: Switched to D3D backend again, a heavily consistent theme is that textures with the mess at the bottom are the ones that refuse to load. Just a wild guess, but because the generated textures don't match what's actually inside the game's files, D3D isn't recognizing (and subsequently able to replace) the originals with the new ones since I am taking the dumped textures and just editing on top of them for the replacements. What's strange about this is either with OGL or D3D enabled, the same textures come out looking messy.

[LunaMoo]

From your screenshot the second texture going from the top left corner is 08fb73d0cdb2ae39e9b4ba13.png and then repeats changing only first 8 digits(which is address), you can just place it in textures.ini file under hashes, like that:

[hashes]
00000000cdb2ae39e9b4ba13 = UI/01.png

And all instances of this texture based on texture and clut hash would be replaced by 01.png stored inside UI subfolder. You can ofc name files like you want and don't need subfolders you can also keep comments in that file using "#" to keep notes etc. For full syntax with usage examples of this textures.ini file you can just visit links which this file will include when generated from ui, maybe also check this thread where this feature was discussed from the start. Same thing should work for that other ui texture, unfortunately if a texture changes both adress and texture hash like those blond heads from your screenshot, you might have to list all duplicates which will only be possible if the number of duplicates is reasonably small.

The UI textures might also generate more duplicates if texture hash ever changes as they also have some unused parts seen as messed up, it's just how psp games reuse parts of textures to better fit psp limitations, ie game had only 400x200 image, but smallest texture size on psp that could fit it would be 512x256, so game will use portion of the texture to store something else. It's not a problem if that other thing is fairy constant or even part of other texture that always shows up, but if it ends up some random data that changes often, then you have to give up as every time it changes, ppsspp will see it as different texture and there's really no solution for this problem for now.

[Vladabdf]

Thanks. I'll also begin my trials with using textures.ini and report back if anything changes. A hunch says nothing will just because of the messy bits, but it's worth a try.

[Vladabdf]

With D3D9, using textures.ini for the most part this seems to fix custom textures not loading, with very few exceptions (blonde head). Thanks so much for helping and responding and being patient with me.