New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Fix efb2tex for Sonic Riders: Zero Gravity #3030
Conversation
Compared to the original code, this probably improves efb2ram quality at higher IRs.
|
In my opinion, this would be fine with texture_size < entry->size_in_bytes. But texture_size != entry->size_in_bytes includes texture_size > entry->size_in_bytes as well. And this would mean that Dolphin ends up using a small efb copy when trying to use a big texture. |
|
Which is exactly the case this is trying to copy with, |
|
But we only know this for this game. In other games, this would be just guessing. If it would only affect efb2tex, it might be fine, as efb2tex is a hack anyways. But this affects efb2ram as well, where efb2ram is working fine for this game already, and now it could be broken for something else. |
|
Hmm, I guess you are right. This will potentially change the behaviour of things that a currently working in only efb2ram. |
|
Why is the NSMBW hack not working here? |
|
I think both, the efb copy and the texture that Dolphin ends up creating, start at the same offset. So the partial texture updates code needs to be updated to support this. Also, Dolphin must not delete the efb copy, in order to be able to use it. Apparently phire is working on a bigger change that makes the partial texture updates code way more general. |
|
This is kind of wanted before the progress report. I don' tlike having huge regressions around a featured change. |
|
As far as I can tell, NSMBWii's coins work in this, too. |
|
I think I'll make this fix apply to efb2tex only, which fixes the regression without causing any new ones. It can be replaced by the new feature when I get around to writing it. |
|
Tick tock, the progress report is coming. Makes it easier for me to write if there aren't regressions to mention! |
|
It also fix the left corner of Sin and Punishment 2. |
|
Is this waiting on anything? |
|
This has been fixed by mimimi's PR |
Was broken by #2960. Compared to the original code, this probably improves efb2ram quality at higher IRs.
The game was padding the size of the efb2ram copy from 640x480 to 1024x512 (power of 2), It didn't actually use the rest of the texture, just leaving it a solid pink color, so our current method of "just give it the efb copy anyway no matter what dimensions, as long as the starting address and hash match" works just fine.
But our efb copy code hashes a 1024x480 texture, while the texture loading code hashes a 1024x512 texture, so they get different results.
The new texture loading code checks the size of the efb copy hash and re-does it's hash to match,