Issue 8317 - Messed up bloom

[TheComet]

Hey guys


A while ago I opened a bug concerning a broken bloom effect in the game "Spyro - A Hero's Tail". The game runs fine safe for this issue.

I recently decided to try and see if I could fix the bug myself. I'm a fairly experienced programmer but the project is overwhelming to take in.

Can someone take a look at this and tell me where I should be looking in the code? If you can give me some hints or theories as to what's causing this that would also help a lot.

FIFO Log

(extension is actually dff.tar.xz, I had to add .bmp so the forums could accept)
(unzip with 7zip or if you're on a *nix based system, tar --xz -xf <file>)


  spyro-a-heros-tail-swamp.dff.tar.xz.bmp (Size: 428.91 KB / Downloads: 151)

Bug Report

The filed bug can be found here: https://bugs.dolphin-emu.org/issues/8317

Video

Here is a video of the bug in action:

https://www.youtube.com/watch?v=spBwTw5AyuA

Screenshots

Here's a screenshot of the issue, notice the smear on the fairy's wings:



apitrace of fifo log replay

I ran an apitrace of the game (using the GL backend) and found some interesting results. The scene I traced can be seen here:



The bug appears during the second downsampling pass of the "glow mask" (these images were scaled up with GIMP):

Initial mask (texture size: 160x122)


First pass (texture size: 80x56)


Second pass (texture size: 40x28)


(If anyone wants the .trace file I can upload it.)

See the result from the second pass? It's all smeared. This should not be happening and this is the cause of the smears seen in the video.

Any ideas what's causing this and where I should be looking?

[KHg8m3r]

What happens when you go to Graphics > Enhancements and check the Disable Fog box?

[JMC47]

This issue cannot be worked around, I definitely agree something is going wrong. I wonder if I can get someone to look at this, this is the most information I've seen on the issue.

[degasus]

For me, this sounds like an issue within the efb copy. The GC GPU does not support render-to-texture, so it must copy the framebuffer content into a texture a lot. But it has a nice feature to scale this copy by half (eg for mipmap generation). Maybe it's worth to monitor the dumped texture format, and/or the format how it should be read.

Feel free to ping me on IRC on #dolphin-dev @ freenode. Most of our development talk is there.

Indeed, apitrace is nice, but do you have also tried to dump this scene as a fifo log? So you can replay it within dolphin deterministic and touch the GPU emulation.

[JMC47]

Added the issue to fifoci. If it's fixed, we'll know about it right away.

[TheComet]

(10-27-2015, 01:12 PM)KHg8m3r Wrote: What happens when you go to Graphics > Enhancements and check the Disable Fog box?

No effect.

(10-27-2015, 06:17 PM)degasus Wrote: For me, this sounds like an issue within the efb copy. The GC GPU does not support render-to-texture, so it must copy the framebuffer content into a texture a lot. But it has a nice feature to scale this copy by half (eg for mipmap generation). Maybe it's worth to monitor the dumped texture format, and/or the format how it should be read.

Thanks, this will definitely give me something to work on/with. I noticed the bloom effect disappears entirely when you disable "Store EFB Copies to Texture Only" too. That's probably related.

What also might be interesting is to see if the bug occurs when running on Windows using the DX backend.

(10-27-2015, 06:17 PM)degasus Wrote: Indeed, apitrace is nice, but do you have also tried to dump this scene as a fifo log? So you can replay it within dolphin deterministic and touch the GPU emulation.

Yeah, the apitrace was actually done on a fifo log replay (completely forgot about that). I updated the first post with a download of the DFF file.

[degasus]

(10-27-2015, 09:30 PM)TheComet Wrote: I noticed the bloom effect disappears entirely when you disable "Store EFB Copies to Texture Only" too.

So there might be two issues:
- We might not load the efb copy afterwards again. This may be because of the game only using parts of it, using it in another format, ....
- The game itself copies those bits to another location. Then there is no way to fix it but the slow efb copy to RAM :/

So I'd go through all texture decodes and look for one which overlap the last efb copy. Likely you'll find some parameter missmatch there.

[KHg8m3r]

Do you think this issue could be related to this one: https://github.com/dolphin-emu/dolphin/pull/3030

[phire]

Ok, I spent some time looking into this. It's clearer what's happening if the image isn't upscaled with bi-cubic sampling.

This 120x112px texture containing initial mask, which has already been downscaled twice (original size, 640x448):

Is blured into a 80x56px sub-buffer (which is 160x112px because I'm running dolphin at 2xIR) That buffer is then copied into a 80x56px texture in ram.



The texture is then loaded, as a 40x28px texure.



Because the texture in ram is not a 48x28px texture, we get the wrong result trying to load it. Because of the GameCube's texture format, we get the top 8th of the image, but in a pattern of 4 rows of pixels containing the left half, then 4 rows containing the right half (which is black in this case) repeating. 

Clearly, the previous copy from efb to ram was mean to downscale by 50%, but it didn't. Either because dolphin messed up and didn't downscale, or dolphin had a cpu bug causing the game to never ask for the image to be downscale (or 3rd possibility, this game is actually broken on the a real gamecube too, and nobody noticed.)