• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 ... 19 20 21 22 23 ... 116 Next »

In regards to poor bloom and what not to scale. Xenoblade test fixes.
View New Posts | View Today's Posts

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
In regards to poor bloom and what not to scale. Xenoblade test fixes.
01-15-2018, 07:03 AM (This post was last modified: 01-30-2018, 01:14 PM by One More Try.)
#1
One More Try Offline
Posting Freak
*****
Posts: 886
Threads: 23
Joined: Dec 2014
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
[Image: EMFy5L1.jpg]
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).
.zip   SX4E01.zip (Size: 173.1 KB / Downloads: 293)
Find
Reply
01-26-2018, 10:19 AM
#2
Alovon
Unregistered
 
(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
[Image: EMFy5L1.jpg]
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]
Reply
01-26-2018, 11:07 AM
#3
MayImilae Offline
Chronically Distracted
**********
Administrators
Posts: 4,568
Threads: 119
Joined: Mar 2011
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~
[Image: RPvlSEt.png]
AMD Threadripper Pro 5975WX PBO+200 | Asrock WRX80 Creator | NVIDIA GeForce RTX 4090 FE | 64GB DDR4-3600 Octo-Channel | Windows 11 22H2
MacBook Pro 14in | M1 Max (32 GPU Cores) | 64GB LPDDR5 6400 | macOS 12
Find
Reply
01-27-2018, 01:14 PM (This post was last modified: 01-29-2018, 02:50 PM by One More Try.)
#4
One More Try Offline
Posting Freak
*****
Posts: 886
Threads: 23
Joined: Dec 2014
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
Find
Reply
02-04-2018, 07:35 PM
#5
One More Try Offline
Posting Freak
*****
Posts: 886
Threads: 23
Joined: Dec 2014
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.
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode