Emulator Issues #12514
closed
The emulator started not to read texture packs since version 14139
0%
Description
VideoCommon: move all texture calculations to a "TextureInfo" class
After this change, the emulator simply does not read the texture packs
Try it on NFS MW or NFS Underground 2
[Reproduction steps here]
Since 5.0-14139
Is the issue present in the latest stable version?
[Yes/No and version number here]
Yes, all versions after 14139 and stable version
If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)
[First broken version number here (if applicable)]
5.0-14139
If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer
[Attach any fifologs if possible, write a description of fifologs and screenshots here to assist people unfamiliar with the game.]
What are your PC specifications? (CPU, GPU, Operating System, more)
[PC specs here]
Snapdragon 845, Android 10
Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)
[Anything else here]
Just go back to reading mode as it was before. The current change had no positive effect on the reading of textures or on the experience of use. Maintaining it would force everyone to change the order of the names of the pngs to conform to this current standard that does not improve the emulation experience at all.
Files
Updated by JosJuice over 3 years ago
- Milestone set to Current
- Regression changed from No to Yes
- Regression start set to 5.0-14139
Do you have a link to a texture pack that can be used for reproducing this?
Maintaining it would force everyone to change the order of the names of the pngs to conform to this current standard
To clarify, does this mean that the custom textures start working again if they are renamed? If so, in what way do they need to be renamed? 5.0-14139 was not intended to change the naming format of custom textures at all, so this is surprising to me. I would rather expect the problem to be some kind of bug that prevents custom textures from working.
Updated by Vinydasilveira over 3 years ago
- File IMG_20210520_134331.jpg IMG_20210520_134331.jpg added
After this change, the order of texture names changed. Even the dump textures create the textures in another order. And it doesn't make sense to have to rename all the texture packs ever created because of that.
Tested with games other than NFS, such as RE4 Wii edition, Mario Sunshine and also are not working
Link to the NFSMW texture pack, which worked. password: Mi8Pro
https://www.mediafire.com/file/x7ljjlcvx450t8c/MostWantedNewHDTextures.7z/file
Updated by JosJuice over 3 years ago
- Status changed from New to Accepted
Ah, so the difference is that the m_ part of the filename is now gone? Thanks – that's the critical piece of information. Marking the issue as accepted.
Updated by Techjar over 3 years ago
Are both of the textures shown in the screenshot dumped? Or is one of them a hires texture? We're a bit confused as to why they look drastically different.
Also, can you please provide a fifo log from an area in the game containing one of the changed texture names? It would be very helpful in debugging this.
Updated by Vinydasilveira over 3 years ago
The textures print is just an example. What matters is the order that has changed without any benefit.
Updated by iwubcode over 3 years ago
Vinydasilveira wrote:
The textures print is just an example. What matters is the order that has changed without any benefit.
The perceived benefit of the 'TextureInfo' change is not visible yet, this was an intermediate change to prepare for something more interesting.
The change you're mentioning shouldn't have had any functional impact. If you're seeing differences, that's a bug. I'm not sure what you mean by "order".
We tested a bit yesterday and didn't notice any changes with the texture dumping when reviewing your screenshot.
Today, I tested texture pack loading on a number of games and have not noticed any issues. If there is an issue it's not immediately obvious or there is something specific to the game you are trying to play.
Please provide the requested fifo. That will allow us to test your game with the texture pack you have linked and see the issue you are experiencing.
Updated by Vinydasilveira over 3 years ago
I don't know how to do that. What I do know is that going back to any version prior to 14139 my texture packs are back up and working.
Updated by Vinydasilveira over 3 years ago
- File Screenshot_2021-05-21-20-05-14-578_com.speedsoftware.explorer.jpg Screenshot_2021-05-21-20-05-14-578_com.speedsoftware.explorer.jpg added
Look. Again, this time with the same dump Textures (I don't know how I can be clearer and more objective than that), but one from the buggy version and the other from any version before 14139. Now the emulator doesn't read or create the textures with o this letter "M", ( witch is default prior to version 14139) which wouldn't be a problem if I didn't have to change more than 100k of pngs to the new default without the letter "M"
Updated by JMC4789 over 3 years ago
We've accepted it is a bug. We're saying that this was not an anticipated behavior we wanted to happen.
We will attempt to fix this bug, as texture hashes should not have been affected.
Updated by Vinydasilveira over 3 years ago
I did some tests here. All the pngs that I removed the "m" the emulator managed to load.
Updated by iwubcode over 3 years ago
We've figured out the issue. The current code only puts "_m" is there are actual mipmaps. However, it seems some games have mipmaps enabled but never create any. These games are missing the "_m". The old code mistakenly puts a "_m" even when there aren't any mipmaps.
In order to keep things compatible, we will be opening a PR to address the issue.
Updated by iwubcode over 3 years ago
Should be fixed by: https://github.com/dolphin-emu/dolphin/pull/9737 . Please test
Updated by iwubcode over 3 years ago
For reference, here's the windows build: https://dl.dolphin-emu.org/prs/0d/cb/pr-9737-dolphin-latest-x64.7z
Updated by iwubcode over 3 years ago
We noticed you were on android, so here's the build for that: https://dl.dolphin-emu.org/prs/d3/39/pr-9737-dolphin-latest.apk
Updated by Vinydasilveira over 3 years ago
It's working! I understand that the issue of m is an old Error, maybe with time and awareness of all modders we can redo the names to this new default.
Anyway. Thank you very much
Updated by 
Updated by leoetlino over 3 years ago
- Fixed in set to 5.0-14263