Closed LunaMoo closed 8 years ago
Changing:
entry->fullhash = QuickTexHash(replacer, entry->addr, entry->bufw, w, h, GETextureFormat(entry->format), entry);
back to:
u32 fullhash = QuickTexHash(replacer, entry->addr, entry->bufw, w, h, GETextureFormat(entry->format), entry);
fixes this, @unknownbrackets ? https://github.com/hrydgard/ppsspp/commit/4ce02e0920646fa38f5ab3adf40fc74963141126
nextNeedsRehash
explicitly means entry->fullhash
needs updating. That code was just a dumb mistake, introduced in 6bd86f462d1f90c3e65d1e64dfb777248ce4c09c. I assume it worked prior to that commit?
In that scenario, we're rebuilding the texture because of something other than a hash change. If we don't set its hash, we'll rebuild it again if the hash also happened to change, which will just waste time.
If you replace these lines:
gstate_c.textureFullAlpha = entry->GetAlphaStatus() == TexCacheEntry::STATUS_ALPHA_FULL;
gstate_c.textureSimpleAlpha = entry->GetAlphaStatus() != TexCacheEntry::STATUS_ALPHA_UNKNOWN;
With:
gstate_c.textureFullAlpha = false;
gstate_c.textureSimpleAlpha = false;
Does it also "fix" it?
-[Unknown]
Yes, changing those to false has same effect as reverting that line. Also yes it worked in earlier versions, I just didn't notice that code in whole was part of it when checking what started the glitches from the end.
Hmm, is there another game that reproduces this?
I'd suggest logging here:
entry.SetAlphaStatus(alphaStatus, level);
Something like:
if (entry.addr == 0x090ba3c0) {
NOTICE_LOG(HLE, "alphaStatus -> %x, fmt=%d, bufw=%d, size=%dx%d", alphaStatus, dstFmt, bufw, w, h);
}
entry.SetAlphaStatus(alphaStatus, level);
And see what's different between entry->fullhash
and u32 fullhash
. Somewhere it must be detecting the alpha status incorrectly... but assuming you're not using replacements, BuildTexture()
should always set those, so I don't see why making the hash invalidate once would help...
Maybe somewhere is reading textureFullAlpha
too early... you could add logging to each place that reads it (when the current texture matches that address), and see if anywhere reads it before it's set?
-[Unknown]
Didn't played much so don't really know, but Kenka Banchou jp version has a demo ~ http://www.pspdemocenter.com/demos/NPJH90015/EBOOT.PBP the glitch can be reproduced by watching first cutscene, main character hair seems affected althrough it's kind of hard to notice without comparing:
Edit: as for the log from the grass texture, both show only this, once:
alphaStatus -> 4, fmt=5121, bufw=128, size=128x128
Pretty sure something is reading it early... hunting it down.
By the way, I think I never realized this had a demo. Darn.
Broken by: 010a7ac1af0ca39f2f8cee8ef685069ed582944f, actually not, was wrong even before that.
-[Unknown]
Okay, that should do the trick. May fix similar glitches in other games too.
-[Unknown]
Thanks for fixing:). As for demo I just found it on this list http://apps.curtrostudios.com/pspdemos/ which someone recently linked either in some other issue or forums. Stores only xpd files, but link can be found inside with any text editor. Might be usefull since it has a lot of japanese games demos and those tend to often be quite literally "hidden" on official game sites even through it should be part of advertisement.
Starting from v1.2.2-371-g2c84411 / https://github.com/hrydgard/ppsspp/commit/2c84411426fa74c6b2eefb62c6b7441c696fa697
How it looks now: How it looked/should look:
Settings:
Texture:
A bit weird, but when stepping prim in GE debugger for the grass texture, it's drawn correctly for that frame.