In regards to poor bloom and what not to scale. Xenoblade test fixes.

[One More Try]

Updated code thread: https://forums.dolphin-emu.org/Thread-high-ir-bloom-fixes-for-xenoblade-and-more

In some discussions about bad bloom from scaled efb there was the question of how to choose when to NOT scale something.  I'm curious if you could use the name of the texture that gets manipulated/scaled for bloom as an identifier.  It's easy to manually determine the textures being used to create bloom, so if someone made a quick list of those textures, can they be treated differently?

Also, when Xenoblade makes blooms, it blurs (downsamples?) the efb copy multiple times, but high IR prevents it from becoming blurry/small enough to look right. I don't know if dolphin could detect that operation and make it more effective - or if it's used by other things that shouldn't be touched.

I found where in Xenoblade's code the Bloom effect is created, so if those options don't work I wonder if I can force it to make a smaller copy (it's 20x16 for native and then gets bigger with IR). 80ca3fa0 determines how many passes are made, making a smaller copy each time (010?0000 ?=passes), but it makes the effect larger too. The code also keeps track of the efb copy size, which is incorrect for higher IRs. 80ca3fa4 can be decreased to manipulate a part of what keeps track of the size.

If we make it do 2 more copies to get a smaller size 80ca3fa0 = 01050000 (two more passes for IR x4 I think?)
If we scale a part of the texture height calc (copy offset?) 80ca3fa4 = 3f000000 (inversed -> x4)
Then change a brightness constant 8066AB10 = 3fa99999 (double = 0.5 ? = 1/4th)  -- Can also change brightness with 80ca3f8c
We get something better than doing nothing, but not the same as Native. Test on Makna forest torches, other game areas can overwrite values.
AR
$Bloom Test 4xIR some game areas overwrite
04ca3fa0 01050000
04ca3fa4 3f000000
0466AB10 3fa99999

I tried to increase the initial texture size for more room to scale down, but because it always scales the texture according to IR, it's not a good option.

/edit Instead of the above, we can force the texture size to be smaller, but there's an initial alpha mask that's too sharp and makes it a bit grainy still. Also, it would get too small for IR higher than 4. (actually, pushing it ito IR 8 could cause the numbers to go to 5px,4px so maybe that's okay?).
$Gecko Bloom x4 IR
C249E5AC 00000002 //Tex Height divide by 4
7C6503D6 5463F0BE
5484F0BE 00000000
04ca3fa4 3f000000 //Offset Factor correction

4x IR Bloom Hack Fix: (Show Spoiler)

L: Fix, R: Normal

I'll include my symbol file for this. Search: Bloom_Copies   also I make heavy use of single line comments, which display well in 5.0-3819 (not the last version to do this).
  SX4E01.zip (Size: 173.1 KB / Downloads: 94)

[Alovon]

(01-15-2018, 07:03 AM)One More Try Wrote: In some discussions about bad bloom from scaled efb there was the question of how to choose when to NOT scale something.  I'm curious if you could use the name of the texture that gets manipulated/scaled for bloom as an identifier.  It's easy to manually determine the textures being used to create bloom, so if someone made a quick list of those textures, can they be treated differently?

Also, when Xenoblade makes blooms, it blurs (downsamples?) the efb copy multiple times, but high IR prevents it from becoming blurry/small enough to look right. I don't know if dolphin could detect that operation and make it more effective - or if it's used by other things that shouldn't be touched.

I found where in Xenoblade's code the Bloom effect is created, so if those options don't work I wonder if I can force it to make a smaller copy (it's 20x16 for native and then gets bigger with IR). 80ca3fa0 determines how many passes are made, making a smaller copy each time (010?0000 ?=passes), but it makes the effect larger too. The code also keeps track of the efb copy size, which is incorrect for higher IRs. 80ca3fa4 can be decreased to manipulate a part of what keeps track of the size.

If we make it do 2 more copies to get a smaller size 80ca3fa0 = 01050000 (two more passes for IR x4 I think?)
If we scale a part of the texture height calc (copy offset?) 80ca3fa4 = 3f000000 (inversed -> x4)
Then change a brightness constant 8066AB10 = 3fa99999 (double = 0.5 ? = 1/4th)  -- Can also change brightness with 80ca3f8c
We get something better than doing nothing, but not the same as Native. Test on Makna forest torches, other game areas can overwrite values.
AR
$Bloom Test 4xIR some game areas overwrite
04ca3fa0 01050000
04ca3fa4 3f000000
0466AB10 3fa99999

I tried to increase the initial texture size for more room to scale down, but because it always scales the texture according to IR, it's not a good option.

/edit Instead of the above, we can force the texture size to be smaller, but there's an initial alpha mask that's too sharp and makes it a bit grainy still. Also, it would get too small for IR higher than 4. (actually, pushing it ito IR 8 could cause the numbers to go to 5px,4px so maybe that's okay?).
$Gecko Bloom x4 IR
C249E5AC 00000002 //Tex Height divide by 4
7C6503D6 5463F0BE
5484F0BE 00000000
04ca3fa4 3f000000 //Offset Factor correction

4x IR Bloom Hack Fix: (Show Spoiler)

L: Fix, R: Normal

I'll include my symbol file for this. Search: Bloom_Copies   also I make heavy use of single line comments, which display well in 5.0-3819 (not the last version to do this).

Is the code compatible with only the American ROM? 

I turned the code on and have the game at 1440p internally and the problem still persists. 
Could it be because I am running an PAL ROM? 

If so can you help out with making the code work with it? 
Also I am using a modified ROM as my main game-play base (Rickv123's HD Expansion)  But other Gecko codes work with that just as fine sense it uses the PAL rom as a base. If that is the case, why not talk with him to see what the problem is.[color=#006abd] [/color]

[MayImilae]

Awesome! I'll definitely be using this in xenoblade!

Now I hate to be *that* person, but Metroid Prime 3 could really benefit from this too~

[One More Try]

I'll release a better version of the code soon and take bug reports in the cheats / game patches forum.

A custom one could probably be made for Metroid. I looked at another game and it was more complicated than Xenoblade, so not 100% sure... unless there's a full symbols file for metroid prime 3?

https://forums.dolphin-emu.org/Thread-high-ir-bloom-fixes-for-xenoblade-and-more

[One More Try]

20 pixel bloom copies can't be adjusted for at x8 IR because you have to divide 20 by 8 for scaled efb to remake a 20 pixel image, and that doesn't work. Another suggestion if this can't be fixed globally: allow a flag to be set in memory and check if the flag is set when scaling efb copies. If the flag is ON, don't scale. Then the flag can be manually set in each game's code. Not an ideal solution I know, but way easier and perfectly accurate if the game's code must be edited to fix it.