Emulator Issues #13128
openXenoblade Chronicles bloom on title screen is much stronger than console
0%
Description
Xenoblade Chronicles (SX4E01, USA, Good dump, ISO/RVZ)
What's the problem? Describe what went wrong.
During the sunset part of the title screen sequence, bloom is way too large. On console you can see nice dramatic clouds in the sunset, but on Dolphin that whole part of the screen is basically a solid orange color.
Dolphin is accurate here with the software renderer, but all other backends have this issue no matter what settings I try to change. I mainly tested things at native Internal Resolution, but this setting is odd as the title screen is part of the EFB or something, so increasing resolution only works with Scaled EFB Copy enabled. When that setting is enabled, changing IR does nothing to the bloom, everything just becomes HD as it should. However if Scaled EFB Copy is disabled, increasing the resolution slightly reduces bloom, but only on even numbered IR scales? Some settings do decrease the bloom a little bit, like 8xMSAA or Disable EFB VRAM Copies, but none of these are real solutions.
Using a bloom gecko code is helpful, but they're all slightly off and tend to mute the pink sunset colors a bit.
Please note I've looked at nothing but the title screen, and have no idea about the state of things like torches or lamps
What steps will reproduce the problem?
Just boot up the game and fast forward a bit. Once the sun starts setting, you'll soon see an orange color fill up the top right of the screen. The sunset lasts a while, so you can easily make a save state to check out the scene in the software renderer.
Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.
I tested most things on the beta build 5.0-17995, but I updated to the latest dev version 5.0-18078 and its still there
Is the issue present in the latest stable version?
Yeah, 5.0 has it. So does 4.0 and 3.5, but 3.0 is strange.
Stable 3.0 is the only version I tested that doesn't completely mess up the scene at default settings. The bloom is still wrong, but at least its not covering the entire top right of the screen. Something else I only saw on 3.0 is that the graphics get very blurry right when the sunset starts, like the game has just changed something, then when sunset turns to night, the game goes back to the normal blocky low res graphics.
The earliest dev build I could find on the website was 3.0-749, but at default settings it does the heavy bloom like every other Dolphin version. However if you change the EFB Copies setting to RAM, you still get bad bloom but its a unique form of bad. This EFB Copies thing worked on 3.0-749, 3.0-936, and 3.0-937 aka 3.5-0, but I couldn't get stable 3.5 to do this.
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
I've got a three frame fifolog but I don't know if it'll help anything. It was recorded in either 5.0-17995 or 5.0-18078.
I've also got some screenshots, plus I made some comparison images because I've got nothing better to do
What are your PC specifications? (CPU, GPU, Operating System, more)
AMD R5 3600
Nvidia 1050 (driver 516.94)
Windows 10 Home 21H2 Build 19044.2364
I've also tested it on someone else's computer with a R7 3700x and 3060 ti (unknown drivers / windows 10). I haven't tried any AMD or Intel GPUs.
Android 5.0-17269 (from F-Droid) also has the issue.
Is there anything else that can help developers narrow down the issue?
This probably doesn't help, but you can easily find old youtube videos that show title screen on Wii or Dolphin
Here's an old Wii video, check out the right side starting around 1:45: https://youtu.be/3OZoockxQmY
Even this classic 2011 Dolphin video has the error in it starting around 1:37: https://youtu.be/wgPcl1WJ98Y
Files
Updated by milebon almost 2 years ago
wait i'm new to this how do i embolden text or attach multiple files
Updated by milebon almost 2 years ago
- File compare xenoblade dolphin 1.png compare xenoblade dolphin 1.png added
- File Xenoblade 1xIR no cheats D3D11 no enhance 5.0-17995 SX4E01_2022-12-22_14-05-53.png Xenoblade 1xIR no cheats D3D11 no enhance 5.0-17995 SX4E01_2022-12-22_14-05-53.png added
javascript was off so the editor was barren, my b
anyways guess i'll just add some files here. i'm assuming its 5MB per batch, not per file?
Updated by milebon almost 2 years ago
- File compare xenoblade dolphin 2.png compare xenoblade dolphin 2.png added
- File Dolphin Stable 3.0 Default Settings Xenoblade SX4E01-1.png Dolphin Stable 3.0 Default Settings Xenoblade SX4E01-1.png added
- File Xenoblade no cheats Software render 5.0-17995 SX4E01_2022-12-22_15-14-55.png Xenoblade no cheats Software render 5.0-17995 SX4E01_2022-12-22_15-14-55.png added
sorry, sorry
Updated by milebon almost 2 years ago
- File Dolphin 3.0-749 EFB Copies set to RAM Xenoblade SX4E01-2.png Dolphin 3.0-749 EFB Copies set to RAM Xenoblade SX4E01-2.png added
- File Xenoblade 1xIR $bloom 4x IR D3D11 no enhance 5.0-17995 SX4E01_2022-12-22_15-35-58.png Xenoblade 1xIR $bloom 4x IR D3D11 no enhance 5.0-17995 SX4E01_2022-12-22_15-35-58.png added
one more time for the fans
Updated by milebon almost 2 years ago
(edit: i'm dumb and stable 3.5 can do the efb copies ram thing)
Updated by taolas almost 2 years ago
The bloom codes reduce the size of the efb bloom copies. They should be used with the corresponding IR. Using IR x1 Bloom x4 wouldn't be used in actual gameplay. Though it's good to note that it affects this problem.
I'm no expert, but as far as I can tell the software renderer turns a 20x16 efb copy that's a spherical bloom image into a 10x8 efb copy with a black diagonal line through the middle of it. This line is then used for blending even smaller EFB copies, which makes the end result darker and less yellow. Non-software renderer doesn't produce the black diagonal line and thus it turns out brighter and more yellow.
Updated by pokechu22 almost 2 years ago
- Related to Emulator Issues #12576: Skyward Sword: Software Renderer produces a more accurate video than any other backend added
Updated by pokechu22 almost 2 years ago
- File Sunset Dolphin 5.0-17995 Software Renderer.png Sunset Dolphin 5.0-17995 Software Renderer.png added
- File Sunset Dolphin 5.0-17995 Vulkan No MTS No Disable VRAM.png Sunset Dolphin 5.0-17995 Vulkan No MTS No Disable VRAM.png added
- File Sunset Dolphin 5.0-17995 Vulkan No MTS Yes Disable VRAM.png Sunset Dolphin 5.0-17995 Vulkan No MTS Yes Disable VRAM.png added
- File Sunset Dolphin 5.0-17995 Vulkan Yes MTS No Disable VRAM.png Sunset Dolphin 5.0-17995 Vulkan Yes MTS No Disable VRAM.png added
- File Sunset Dolphin 5.0-17995 Vulkan Yes MTS Yes Disable VRAM.png Sunset Dolphin 5.0-17995 Vulkan Yes MTS Yes Disable VRAM.png added
- File Sunset real hardware.png Sunset real hardware.png added
- Status changed from New to Accepted
This seems fairly similar to #12576. I did some testing using the hardware fifoplayer and can definitely see the difference. The software renderer is fairly close (though not perfect), while Vulkan is fairly wrong. Checking "Disable EFB VRAM Copies" makes a slight difference, while checking "Manual Texture Sampling" makes a larger difference but still isn't correct.
(As a quick note, fifologs store graphics data in a way that can be replayed, even if you change the graphics backend, making it useful for trying the software renderer and for comparing exactly the same frame with different settings (no need to mess with savestates). In some cases data from EFB copies gets baked into them, particularly if it only copies on one frame and then re-uses that on many later frames, but it seems to work fine for this one. They can be played either directly from Dolphin or using the hardware fifoplayer (on real hardware or in dolphin); I used the hardware fifoplayer in dolphin to avoid aspect ratio differences when comparing with real hardware mainly.)
"However if Scaled EFB Copy is disabled, increasing the resolution slightly reduces bloom, but only on even numbered IR scales?" - I believe this is because on odd IR scales, it can just use the center pixel (compare what's done for bounding box), but on even scales, it has to average the middle 4 pixels (I think, at least; I'm not sure what's actually done for either bounding box or this)).
One other note: to my understanding, the limit is 5MB per file, but you can definitely upload multiple files at the same time as long as each one is under the limit. I'm not sure how that works with JS disabled though.
Updated by taolas almost 2 years ago
- File xenosplash.jpg xenosplash.jpg added
I set efb copies smaller than width = 15 to 0 size. Here is software (left) vs opengl (right) comparison.
Updated by taolas almost 2 years ago
I don't know if it's valid to compare the bloom dumped from software renderer as a texture to the bloom dumped as an EFB from OpenGL. I think what I said before applies. Software - Black pixels are inserted into the 10 width copy, which affects blending/iterating. Opengl - no black pixel and the red pixels slowly get more yellow with each iteration. Is software renderer dumping it as a texture important? Like, if other backends handled EFBs so that "texture dumping" would catch them, would that allow the efb to be treated the same as it is in software renderer?
Updated by pokechu22 almost 2 years ago
- File xenoblade_sunset_steps_hw.7z xenoblade_sunset_steps_hw.7z added
- File Bloom efb contents Dolphin 5.0-17995 Software.png Bloom efb contents Dolphin 5.0-17995 Software.png added
- File Bloom efb contents Dolphin 5.0-17995 Vulkan.png Bloom efb contents Dolphin 5.0-17995 Vulkan.png added
- File Bloom efb contents real hardware.png Bloom efb contents real hardware.png added
It looks like you've correctly identified a difference with the software renderer, but I think it's a separate bug: the software renderer probably isn't decoding textures properly when dumping them (perhaps it's treating the 10-wide EFB copy as if it were 12-wide or vice versa, due to how textures are encoded on the Wii; that would produce the same diagonal line). I recently made a change to how the software renderer dumps textures and might have broken this in that; I'll check.
I dumped the EFB contents using the hardware fifoplayer for each step in the bloom process (starting with the whole thing, then subtracting one step at a time (I skipped several initial ones that were unrelated to bloom as well). This ended up being a bit of a tedious process, so I'm not going to do that on Dolphin, but I can show what the EFB contents on the final bloom step are. In the attached images (but not the 7z file), I edited it so that the bottom-left corner is the contents of the top-left 40 by 20 region upscaled 8x along with the neighboring 40 by 40 region upscaled 6x; in the original images that whole region was black. The main thing I see there is that the original texture is the same on Dolphin and real hardware, while the subsequent steps get brighter each time on Dolphin's hardware backends, with the smallest ones ending up extremely bright. The software renderer doesn't have this issue for the most part (and also doesn't appear to have the same black lines).
Updated by pokechu22 almost 2 years ago
I can't reproduce the black line on 5.0-17995, but I can reproduce it on 5.0-17269, so it looks it was an issue fixed by my change (probably this commit as it made it properly use the stride).
Updated by taolas almost 2 years ago
Ah sorry, I must have been using a slightly older build to dump it.
I have a custom build where I can insert a custom shader into the efb pipeline. On OpenGL renderer, I decreased the first 80-width bloom copy's color by 50% and left the rest of the copies alone. The final scene came out roughly equal to software. So that's a massively darker image to start with getting to the same place. The only other thing I noticed was that the first 80-width copy has more desaturated pixels near the brightest area on software, and it's more blotchy and mono-colored on other renderers. Can't really directly compare other copies since it compounds after that.
Updated by JMC4789 almost 2 years ago
So what's actually happening here? Some kind of flaw in the repeated copies?
Updated by taolas almost 2 years ago
- File efb software diff.jpg efb software diff.jpg added
As far as I can see the software renderer makes sharper efb copies, and possibly due to the sharpness, they have slightly different brightness. Repeatedly compounding efb copies makes the differences visible like here, but other times it's not really noticeable, but still present.
I'm not the one who can figure out what code is actually at issue though. Here's an opengl vs software comparison of exhaust pipes used in the efb copies in mario kart wii. 152x114 dimensions, but I just clipped the one small part.
Updated by pokechu22 over 1 year ago
- Related to Emulator Issues #13223: GoldenEye: 007 (Wii) - Bloom lighting effect is stronger than on console added