As stated in the title, certain textures (a small yet noticeable amount) have recently been failing to render in Kid Icarus Uprising for me. I say “recently” because when I first played through the game (on a previous version of Citra), these textures rendered just fine, but one or two updates later, I started noticing that a particular metallic blue texture used for things like the Space Pirate ship (albeit only during the flight section of that level), the walls in the Aurum Hive, and a few crystals in the Reset Bomb Depot was showing up as pitch black. Technically speaking, the game is still playable even with this bug, but it’s worth reporting anyway, just in case it might be linked to a larger issue behind the scenes that I’m not presently aware of. For clarity’s sake, I chose a section of the game with another object that shows what the surrounding environment should look like, i.e., the elevator in the middle of the room.
Oddly enough, I’d seen a previous topic about a similar bug occurring in Star Fox 64 3D with the Arwing’s textures…but only on Intel GPUs. As stated below, my GPU is an Nvidia model, so it shouldn’t be happening for me logically speaking…but equally logical is the possibility that my issue could somehow be related to that one, so if that helps the debugging team figure things out, then I’d say it’s worth mentioning.
Additionally, it should be noted that I was running this at 3x Native resolution (1200x720) with Linear Filtering on, as well as all Advanced options on (Hardware Shader, JIT, Disk Shader Cache, etc).
- Operating System: Windows 10 Home 64-bit
- CPU: AMD Ryzen 7 3700X 8-core (~3.6 GHz)
- GPU: NVIDIA GeForce RTX 2070 SUPER
- Citra Version (found in title bar): Citra Nightly 1784 (HEAD value in screenshot title bar)
- Game: Kid Icarus Uprising (USA)
- Screenshot of Issue (include the full Citra window including titlebar):
NOTE: The forum system does not permit file sizes large enough to match my log file’s (frankly shockingly large) size of over 42 megabytes, so I had to upload it to an external file hosting site. If there is a way around the aforementioned file size limit that the debugging staff would prefer, please message me.
In order for us to provide better support, we need to see the log generated by citra. This guide will walk you through how you can obtain the log file: How to Upload the Log File
The log file appears to have been deleted.
Yes, I was afraid it might do that. Like I had previously said, something about whatever bug was causing the black textures problem was also causing Citra to get so busy that in the time it took me to start up the game, go to a level that would let me reproduce the bug, get to the part of said level that the bug occurred at (which unfortunately wasn’t until halfway through the level), screenshot the bug’s occurrence, and exit out of the game (which itself took almost more than a full minute, much of which was spent with Citra in a “Not Responding” state), the emulator had somehow managed to generate enough log data to make said log over 40MB in size. Given that the other log files I’ve seen on these forums never seem to breach the kilobyte ranges, I’d say that’s pretty abnormal.
Unfortunately, a log file that large also doesn’t get accepted by said forums as an attachment, it would seem, so I have had to resort to an external file sharing site. Last time, it seemed I forgot to set the expiration date for it past two weeks; to be on the safe side, I set this one for an expiration date of one year (the maximum that the site will let me without making an account), but as far as a direct upload to the forums is concerned…this is apparently the closest I can get for this particular log file:
I’m getting a gateway timeout error when trying to access that link. Maybe try Mega, or Google Drive?
…wow. And here I picked that site specifically because I thought it would let me avoid having to go through Google. Alas, if the choice is between Mega and Google Drive…then Google Drive it is.
While looking through that log file myself, though, I did find a particular critical error that repeated a great many times throughout, typically following this pattern, with each X being a digit in a number (game ID number followed by texture ID, perhaps?):
[XXXX.XXXXXX] Render.OpenGL video_core/renderer_opengl/renderer_opengl.cpp:DebugHandler:1229: API ERROR 1282: GL_INVALID_OPERATION error generated. Target doesn’t match the texture’s target.
If my guess is correct, something is causing the OpenGL rendering process to not recognize the textures it is supposed to load, for some reason. Considering that Kid Icarus Uprising worked on previous iterations of Citra with regards to the textures it is now failing to load, and is now generating an exponentially higher number of shaders than it used to prior to…I’m going to say four to six updates ago…could it be an issue with the shader cache, perhaps? If so, is there anything I can do to clear that cache out and let it start over from scratch?
Hmmm, there was a change to the graphics backend recently that invalidated old shader caches. Perhaps yours didn’t get invalidated properly. Try deleting the cache manually:
File>Open Citra Folder, and open up the
shaders folder. Delete the
opengl folder found here and try your game again afterwards.
If that doesn’t work, try out this older Citra build (before the change I mentioned): Release nightly-1782 · citra-emu/citra-nightly · GitHub
Huh…not what I would have expected to cause an absurdly large log file full of numerous failed attempts at loading specific shaders and related assets, much less an unusually large number of shaders to process in the first place (I believe it was getting close to 70,000 the last time I ran this game prior to trying a purge of the opengl folder), but I guess cleaning the slate on it is better than what I feared might have been going on. After prior experiences with Microsoft Office Excel of all things suffering a memory leak while trying to work with it, I was starting to get scared that something about how Citra had recorded KIU’s shaders in previous emulator versions had suddenly come into conflict with the SSD that I have in my computer.
Fortunately, deleting the opengl folder like you said has so far seemed to have fixed the problem, though I’ve only tested it with the textures for the Space Pirate ship, which to be fair were suffering the same issue as the missing textures in the Aurum level shown above. They both have this rather glossy sort of sheen to them, so it could have been a problem with that particular aspect in the graphics backend changes. Regardless, I can see this clean-wipe approach setting my shader-processing back a tad on Ocarina of Time 3D (where it occasionally freezes while loading shaders for the first time, but I think someone else already started a thread on that one), but I’ll deal with that as I have been so far: ye olde “save early, save often” mantra.
Thanks for helping!
As I said in my previous comment, we had a big change to our graphics backend that invalidated old shader caches regardless. Continuing to use older shaders would lead to graphical issues, and even crashes. We pushed a change that made sure that Citra would invalidate those caches (which prompts Citra to delete them). However, there are rare cases, like yours, where that didn’t activate correctly. So whilst I could have given instructions to just remove the shader cache for your Kid Icarus Uprising, given the circumstances, deleting all of the shader caches at the time would be better.
There’s a PR open that should make deleting shader caches (even for individual games) a lot more straight forward to the user. By including an option in the GUI when right clicking on the game. Though it still needs a bit of work: citra_qt: Add options to open/clear the shader cache by GPUCode · Pull Request #6118 · citra-emu/citra · GitHub