Naruto Ultimate Ninja Heroes 2 video flicker fix: Take 3 #18454
Conversation
…transfer detection. The previous attempt was simply flawed.
hrydgard
changed the title
| bool better = !best; | ||
| if (!better) { | ||
| // Heuristics determined from the old algorithm, that we might want to keep: | ||
| // * Lower yOffsets are prioritized. |
There was a problem hiding this comment.
Hm, personally I think this is almost more important than the bind seq (but perhaps not frame written #).
Mostly yOffset = 0 vs yOffset != 0. AFAICT they're not prioritized any other way, right?
-[Unknown]
There was a problem hiding this comment.
Yeah, good point - I'll flip them.
| // Seems likely we are looking at a potential copy of 32-bit pixels (like video) to an old 16-bit buffer, | ||
| // which is very likely simply the wrong target, so skip it. See issue #17740 where this happens in Naruto Ultimate Ninja Heroes 2. | ||
| // If we had scoring here, we should strongly penalize this target instead of ignoring it. |
There was a problem hiding this comment.
If we continue having problems with this heuristic, I don't think it's so bad to specifically ignore it on double size. That's a very strong signal of a color depth mismatch and less likely to be a false error than a slight size discrepancy... I feel like it makes more sense than the 0x1000 fuzz.
-[Unknown]
There was a problem hiding this comment.
Yeah, I'll change the comment, as this heuristic should be really good indeed.
To fix #17740, hopefully with something that will stick this time.
This replaces the previous failed attempts at fixing the flicker in Naruto Ultimate Ninja Heroes 2: #18299 #18008
I rewrote the logic more on the lines of the block transfer logic, while trying to change as little as possible functionally. Will hopefully work without breaking things this time.