Project

General

Profile

Actions

Emulator Issues #9809

open

Paper Mario: The Thousand-Year Door Scaled EFB Copy Inconsistent

Added by Techjar almost 8 years ago. Updated almost 7 years ago.

Status:
Questionable
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

Paper Mario: The Thousand-Year Door

Game ID? (right click the game in the game list, properties, info tab)

G8ME01

MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

db9a997a617ee03bbc32336d6945ec02

What's the problem? Describe what went wrong.

The game appears to use EFB copies when it needs render a lot of one particular character, and these don't always upscale as they should, resulting in them looking quite pixellated as would be expected. I've attached a screenshot below of what it's supposed to look like, and what it looks like when the issue occurs. I turned on dump EFB target and checked the EFB copies it's created to render the characters, and they are indeed high resolution, so they just don't seem to be drawing correctly. It seems like this happens when they are first loaded, but then it fixes itself on a scene change if those EFB copies are also used in that scene.

What steps will reproduce the problem?

Go to any point in the game where a lot of a single character is rendered, probably the prologue when a large number X-Nauts attack Mario. It may require multiple attempts to reproduce it.

Which versions of Dolphin did you test on? Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work?

5.0-321

What are your PC specifications? (CPU, GPU, Operating System, more)

Windows 10
Intel Core i7-3930k
NVIDIA GeForce GTX 780

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)

Using Direct3D 11 if it matters.

Here's what it should look like:
image

Here's what the bug looks like (it's a bit zoomed out but you should be able to tell they aren't upscaled, notice the aliasing):
image

Actions #1

Updated by JMC4789 almost 8 years ago

While it is possible the EFB Copy to Texture path is failing, what happens if you force EFB Copies to Texture on. If everything goes boom, there's a good chance of this being unfixable.

Actions #2

Updated by Techjar almost 8 years ago

Well this game requires EFB to RAM for bounding box emulation and the various paper transition effects. Without it, you get garbage effects and broken paper modes.

Actions #3

Updated by Techjar almost 8 years ago

Huh, actually I just tested it and EFB to Texture actually seems to work fine for this game now, and EFB to RAM might not actually be necessary anymore. It obviously still needs bounding box emulation for the paper modes though.

Actions #4

Updated by Techjar almost 8 years ago

Scratch that, some effects still need EFB to RAM to render correctly (or even at all). So, what, are only texture EFB copies scalable, and not RAM EFB copies? And if that's the case, what is going on that's causing this? EFB copies being stored in RAM when they could be stored in a texture?

Actions #5

Updated by JMC4789 almost 8 years ago

It's possible that some of them are just copies and can be upscaled, but certain ones are different special for some reason and are their own copy. Game programmers are weird.

Actions #6

Updated by Techjar almost 8 years ago

Well as far as I can tell these are just textures and don't got modified once created. Could the problem be that I don't have Texture Cache Accuracy set to safe?

Actions #7

Updated by JMC4789 almost 8 years ago

I doubt it. And just because it doesn't modify it doesn't mean one of them can't hit the EFB Copies to RAM path. Whether it's erroneously triggering it or not, I can't tell ya.

Actions #8

Updated by Techjar almost 8 years ago

Yeah my best guess is it's erroneously triggering the EFB to RAM path, but I wouldn't have any idea why. If I find anything else relating to this issue I'll report it, but that's all I've got for now.

Actions #9

Updated by JosJuice almost 8 years ago

Just to make sure, you have the Scaled EFB Copies setting turned on, right?

Actions #10

Updated by Techjar almost 8 years ago

Yeah it is turned on. I don't think they would be scaled in any circumstance if it wasn't.

Actions #11

Updated by Bighead.0 almost 8 years ago

This is another issue I've known about for some time. A while back I tried to understand it because I did the textures for these guys in the PMTTYD texture pack. I don't know the technical side of why it happens, but I can share my observations.

To start, EFB to RAM or Texture does not seem to make a difference, at least, which of the two is selected in Dolphin and what textures pop out. Both behave identically. To me it looks like there there are 2 copies of the "completed" X-naut being created, the high rez one which seems invisible and temporary, and the low-res one which Dolphin falls back to if the high rez one is missing. I'll elaborate...

The X-naut textures themselves are assembled from the pieces below (image 1). If these textures are retextured, the X-nauts will effectively be retextured in most cases. It seems sometime before the scene where a bunch of them show up at once, the "complete high rez" X-naut is created from this collection of textures. I believe this happens BEFORE the battle with lord Krump, because if a state is loaded during it, then the fully assembled low resolution textures are used (image 2). This is 100% reproducible. Somewhere, the high rez texture was lost? Load from the save cube, don't use save states, and they will be retextured almost all the time unless it bugs.

If something goes wrong somewhere (such as loading a save state between krump battle and where they are littered across the screen), the game falls back to the low-rez completed X-naut (image 2), which is an animation sequence of 24 textures. If these versions were retextured, then they would be retextured in-game as well. I was too lazy to attempt to remake these though which would have masked the "bug" for anyone using the texture pack.

There are also times in this situation where Dolphin may fail to load any texture at all, or it becomes corrupted, or maybe both of them go missing? In this case the texture shows up invisible or sometimes glitchy. I'm not 100% sure how to reproduce this one, but I've seen it a number of times trying to figure out what was going on and why I was getting low rez versions only sometimes. I've seen it with both using and not using savestates, high rez textures or not, settings irrelevant. Whether the game uses the high rez, low rez, or no texture at all seems completely random regardless of any backend or setting.

Recently a user on the forums has experienced it as well, so I'll kindly borrow his image.

Actions #12

Updated by JMC4789 almost 7 years ago

  • Status changed from New to Questionable

Sounds like this is invalid to me? Maybe? Please? I don't want to close it if there's something to fix on Dolphin's end, but it really doesn't sound like it.

Actions #13

Updated by Techjar almost 7 years ago

Yeah, after taking another look at this, seems that the non-scaled characters are just an oddity in the game's design that the texture pack isn't accounting for, rather than a bug in Dolphin. There is that invisible characters thing though, which probably is a bug in Dolphin.

Actions

Also available in: Atom PDF