Hacking Possible to Disable the Wii's (De)Flicker Filter?

[QuintanaSonBlade]

Hello, I would like to thank you for these contributions, I have been wanting to modify the filter values in WiiWare games for a long time and I have not been successful. I use wwpacker and try to find filter values in file 00000001.app and get no results; I only find some values in 00000006.app, I modify them but the filter is still present. The game is Cave Story (USA) (v258).
Some help?
Thank you!

 

[Maeson]

Don't worry NoobletCheese, as long as we can do something to help it's fine, and it helped me learn too. Although We can't know for certain if the default filters can be only preceded by "060606" or the other in every game, if I remember correctly Disaster: Day of Crisis had one of those hidden without a recognizable string for example, so there might be more.

Fortunately in all de 80+ retail games, and all the wiiware games I looked at, not once I did find those two common filter strings on a file and were other type of data, always video filters.

Hello, I would like to thank you for these contributions, I have been wanting to modify the filter values in WiiWare games for a long time and I have not been successful. I use wwpacker and try to find filter values in file 00000001.app and get no results; I only find some values in 00000006.app, I modify them but the filter is still present. The game is Cave Story (USA) (v258).
Some help?
Thank you!

You need to decompress 00000001.app, if I remember right that game had it compressed and that way you won't find anything. To decompress you need wwcxtool, and the commands needed can be found on prior pages of this thread.

 

[QuintanaSonBlade]

Don't worry NoobletCheese, as long as we can do something to help it's fine, and it helped me learn too. Although We can't know for certain if the default filters can be only preceded by "060606" or the other in every game, if I remember correctly Disaster: Day of Crisis had one of those hidden without a recognizable string for example, so there might be more.

Fortunately in all de 80+ retail games, and all the wiiware games I looked at, not once I did find those two common filter strings on a file and were other type of data, always video filters.



You need to decompress 00000001.app, if I remember right that game had it compressed and that way you won't find anything. To decompress you need wwcxtool, and the commands needed can be found on prior pages of this thread.

Thank you very much, it worked!
the blur is finally gone

 

[mive]

do you think this is a filter? its 02 80 xxxx 02 10 06 .... 06 08 08 0a 0c 0a 08 08 instead of 02 80 xxxx 01 E0

 

[NoobletCheese]

do you think this is a filter? its 02 80 xxxx 02 10 06 .... 06 08 08 0a 0c 0a 08 08 instead of 02 80 xxxx 01 E0

Looks like it to me.

01 E0 = 480
02 10 = 528

Those would be efbHeight for TVNtsc480 and TVPal528 respectively.

My upcoming tool will display the full GXRModeObj in human readable text next to each filter so you can easily tell if its a GXRModeObj, and avoid patching ones that don't correspond to a TVNtsc480p one.

I will also mark any that don't have an adjoining GXRModeObj with a question mark next to them.

In some cases like Donkey Kong and Sonic Colours these are the ones the game actually uses despite not being part of a GXRModeObj, so there's still going to be a bit of guesswork involved

 

[mive]

though, isn't pal 576?

 

[NoobletCheese]

Yes, but there are lots of PAL rendering modes of varying resolutions.
These are the ones listed in the official SDK:

GXPal264Ds
GXPal264DsAa
GXPal264Int
GXPal264IntAa
GXPal528IntDf
GXPal528Int
GXPal524IntAa
GXPal264Ds
GXPal264DsAa
GXPal264Int
GXPal264IntAa
GXPal528IntDf
GXPal528Int
GXPal524IntAa

Ds = "double strike" where it only render approximately half the vertical resolution and duplicate it into the 2nd field (or something like that).

I'm guessing the discrepancy between that and 576 is deliberate underscanning to avoid rendering pixels that would normally get cropped in the TV's overscan zone.

 

[NoobletCheese]

There appears to be a byte signature following vfilters which aren't part of a GXRModeObj:

Donkey Kong: 070000040410101004040043300000800000004330000000000000000015
SonicColors: 00000004040F120F04040049800000000000004330000000000000000000

Being able to identify it this way would dramatically speed up my 'scan for vfilters' function.

I will also include a 'full scan' option just in case, but I'd still like to maximise performance, eg. for patching large game collections.

@MaeseJesus

Would you mind sending me the 30 bytes following the vfilters marked 'no string before it' in your .txt file?

These are for Boom Street, Resident Evil Archives: Remake, and Resident Evil: Umbrella Chronicles.

This would help identify if the signature is reliable.

 

[Maeson]

Yes of course:

Boom Street:
8E FA 35 08 08 0A 0C 0A 08 08 00 00 00 00 00 00 00 00 00 43 30 00 00 00 00 00 00 FF FF FF

Resident Evil Remake:
C9 0F DB 08 08 0A 0C 0A 08 08 00 05 01 03 00 04 02 06 00 3C 80 00 00 00 00 00 00 00 00 00

Resident Evil: Umbrella Chronicles:
64 65 00 08 08 0A 0C 0A 08 08 00 54 6F 70 00 00 00 00 00 00 00 00 07 00 00 00 01 00 00 00

Boom Street does match, the other two certainly are different, albeit 00 3C 80 00 main mean something.

I also checked the games where I saw "20 00 20 00 00 00 00" but none of them seem to share it.

 

[NoobletCheese]

No worries, I should still be able to reduce the scanning time a lot by using different low level functions and technique I learned on AHK forum today.

 

[NoobletCheese]

Development diary

The cloud database should not be needed anymore as I've found a better solution using a lookup table.

Basically generate a text file containing all possible vfilters and byte signatures, and then perform a 'find and replace' for all of them.

This turns out to be much less CPU intensive, to the extent I think USB loaders should be able do it in real time at game launch within a couple of seconds.

edit: in case it turns out being too CPU intensive for the Wii, perhaps we should still have the database anyway. I am curious to know how long patching GXSetCopyFilter takes in Swiss on game launch. I'm trying to keep it to 5 seconds or less in my tool, but PC is different hardware and I'm using assembly for the heavy lifting part.

 

[one-piece]

This looks very promising. I'm really waiting for this.
There is something I didn't understand. Does swiss already implement these patches?

Edit:
I found this
https://ppltoast.wordpress.com/2018/05/11/a-small-look-into-the-gamecubes-copy-filter/
And it confirms

emukidid’s homebrew utility Swiss, when set to force 480p on games, also disables the deflicker filter despite the lack of a progressive scan prompt. FIX94’s Nintendont on Wii also disables the filter when forcing video modes.

 

[NoobletCheese]

There is something I didn't understand. Does swiss already implement these patches?

Yep, if you saw on the previous page, there are links to Swiss source code showing how it finds and patches GXSetCopyFilter by looking for its signature.

 

[Maeson]

Hmmm, I was trying Battalion Wars 2 and it seems it is still filtered even when I changed all the known VFilters. It might be doing similar to Donkey Kong and Sonic Colours... It does not use any of the two used by those games either.

 

[NoobletCheese]

Hmmm, I was trying Battalion Wars 2 and it seems it is still filtered even when I changed all the known VFilters. It might be doing similar to Donkey Kong and Sonic Colours... It does not use any of the two used by those games either.

Can confirm the same problem with NTSC version of the game -- patching all known values doesn't work.

I notice the game appears to disable the filter for a split second when the title screen appears, then a split second later turns it back on. Blink and you'll miss it though.

To my eyes it looks like the 08080A0C0A0808 filter, i.e quite strong and nasty.

Maybe the game is generating the vfilter byte string programmatically at runtime so maybe it doesn't live in the binary as a complete string.

Or maybe it's just their own custom filter that we don't know about yet (my byte signature isn't detecting it).

I'll keep digging, but I think patching GXSetCopyFilter will be the only way to solve it.

edit: I tried rebuilding the wbfs with the patched main.dol in case ULGX's 'use alternate DOL' was failing -- no difference.

 

[NoobletCheese]

I'm not confident Swiss's GameCube patching code for GXSetCopyFilter is compatible with Wii.

In Swiss's GXSetCopyFilterPatch.s, the replacement function references the variable in RAM called VAR_VFILTER_ON at address 0x80002E10.

This means the same var would have to exist at the same RAM location on Wii for it to work, and I suspect it doesn't, based on the following observation:

There are 30 occurrences of '2E10' in Battalion Wars 2 main.dol. For each one I looked at the following ~200 bytes and patched one at a time any instruction for 'compare register x with 0 or 1, then branch if equal'. i.e an instruction that changes code path depending on the value in a register, shortly following a reference to something that has the same address as VAR_VFILTER_ON.

The idea is that hopefully the value in the register will be the value of VAR_VFILTER_ON, and flipping the comparison value should make it evaluate to the boolean opposite and take the code path as if VAR_VFILTER_ON was set to the opposite value.

Flipping some of them had some weird effects like disabling certain graphical elements. Most did nothing, and a couple caused system crash.

The search pattern I used was: 2C xx 00 00 41 82
2C = opcode for 'compare values'
xx = the register to compare
0000 = value to compare with the register
41 = opcode for 'branch if equal'
82 = unsure, but all of Swiss's examples in patcher.c have it.

In the meantime I'll continue developing the vfilter patching tool. I'm also adding an option to patch all viWidths to a custom value for some problematic games (mostly GameCube games that don't obey Nintendont's video width setting).

 

[NoobletCheese]

Just to report I've discovered the binary for GXSetCopyFilter -- its address and length is specified in the .map files created by RVL SDK when compiling .elf's.

Haven't yet figured out how to patch it to stop it from setting the vfilter.

We want it to behave as if the third argument is GX_FALSE (0x00):

void GXSetCopyFilter(
   GXBool      aa,
   const u8    sample_pattern[12][2],
   GXBool      vf,
   const u8    vfilter[7] );

Arguments
aa: If GX_TRUE, use sample_pattern. If GX_FALSE, sample a center pixel.
sample_pattern: The sample pattern for the subpixel. The valid range is 1 to 11.
vf : For GX_TRUE, use vfilter. For GX_FALSE, use the default 1 line filter (i.e 00001516150000 -- what we want)
vfilter: Vertical filter coefficient. The valid coefficient range is from 0 to 63. We recommend that the coefficients have a sum total value of 64.

I'm trying to use the aforementioned strategy of flipping a boolean evaluation by modifying 'compare word immediate' and 'branch if equal' , so far without success.

I checked several games and the binary is the same except for 2 bytes which mysteriously change per game.

But I don't think those bytes are related to anything we're interested in.

 

[NoobletCheese]

Hunk:   Kind=HUNK_GLOBAL_CODE     Name="GXSetCopyFilter"  Size=484
8001E880: 2C030000  cmpwi    r3,0x0000
8001E884: 418200F8  beq      *+248                   ; 0x8001E97C
8001E888: 89040000  lbz      r8,0(r4)
8001E88C: 38000000  li       r0,0
8001E890: 89440001  lbz      r10,1(r4)
8001E894: 38600000  li       r3,0
8001E898: 5100073E  insrwi   r0,r8,4,28              ; rlwimi     r0,r8,0,28,31
8001E89C: 88E40006  lbz      r7,6(r4)
8001E8A0: 51402636  insrwi   r0,r10,4,24             ; rlwimi     r0,r10,4,24,27
8001E8A4: 8904000C  lbz      r8,12(r4)
8001E8A8: 50E3073E  insrwi   r3,r7,4,28              ; rlwimi     r3,r7,0,28,31
8001E8AC: 38E00000  li       r7,0
8001E8B0: 5107073E  insrwi   r7,r8,4,28              ; rlwimi     r7,r8,0,28,31
8001E8B4: 8944000D  lbz      r10,13(r4)
8001E8B8: 89640007  lbz      r11,7(r4)
8001E8BC: 39000000  li       r8,0
8001E8C0: 51472636  insrwi   r7,r10,4,24             ; rlwimi     r7,r10,4,24,27
8001E8C4: 89440002  lbz      r10,2(r4)
8001E8C8: 89240012  lbz      r9,18(r4)
8001E8CC: 51632636  insrwi   r3,r11,4,24             ; rlwimi     r3,r11,4,24,27
8001E8D0: 5140452E  insrwi   r0,r10,4,20             ; rlwimi     r0,r10,8,20,23
8001E8D4: 8944000E  lbz      r10,14(r4)
8001E8D8: 5128073E  insrwi   r8,r9,4,28              ; rlwimi     r8,r9,0,28,31
8001E8DC: 89240013  lbz      r9,19(r4)
8001E8E0: 5147452E  insrwi   r7,r10,4,20             ; rlwimi     r7,r10,8,20,23
8001E8E4: 89440003  lbz      r10,3(r4)
8001E8E8: 51282636  insrwi   r8,r9,4,24              ; rlwimi     r8,r9,4,24,27
8001E8EC: 89240014  lbz      r9,20(r4)
8001E8F0: 51406426  insrwi   r0,r10,4,16             ; rlwimi     r0,r10,12,16,19
8001E8F4: 8944000F  lbz      r10,15(r4)
8001E8F8: 5128452E  insrwi   r8,r9,4,20              ; rlwimi     r8,r9,8,20,23
8001E8FC: 89240015  lbz      r9,21(r4)
8001E900: 51476426  insrwi   r7,r10,4,16             ; rlwimi     r7,r10,12,16,19
8001E904: 89440004  lbz      r10,4(r4)
8001E908: 89640008  lbz      r11,8(r4)
8001E90C: 51286426  insrwi   r8,r9,4,16              ; rlwimi     r8,r9,12,16,19
8001E910: 5140831E  insrwi   r0,r10,4,12             ; rlwimi     r0,r10,16,12,15
8001E914: 89440010  lbz      r10,16(r4)
8001E918: 89240016  lbz      r9,22(r4)
8001E91C: 5163452E  insrwi   r3,r11,4,20             ; rlwimi     r3,r11,8,20,23
8001E920: 89640009  lbz      r11,9(r4)
8001E924: 5147831E  insrwi   r7,r10,4,12             ; rlwimi     r7,r10,16,12,15
8001E928: 89440005  lbz      r10,5(r4)
8001E92C: 5128831E  insrwi   r8,r9,4,12              ; rlwimi     r8,r9,16,12,15
8001E930: 89240011  lbz      r9,17(r4)
8001E934: 51636426  insrwi   r3,r11,4,16             ; rlwimi     r3,r11,12,16,19
8001E938: 8964000A  lbz      r11,10(r4)
8001E93C: 5140A216  insrwi   r0,r10,4,8              ; rlwimi     r0,r10,20,8,11
8001E940: 8944000B  lbz      r10,11(r4)
8001E944: 5127A216  insrwi   r7,r9,4,8               ; rlwimi     r7,r9,20,8,11
8001E948: 88840017  lbz      r4,23(r4)
8001E94C: 39200001  li       r9,1
8001E950: 5163831E  insrwi   r3,r11,4,12             ; rlwimi     r3,r11,16,12,15
8001E954: 5143A216  insrwi   r3,r10,4,8              ; rlwimi     r3,r10,20,8,11
8001E958: 5088A216  insrwi   r8,r4,4,8               ; rlwimi     r8,r4,20,8,11
8001E95C: 5120C00E  insrwi   r0,r9,8,0               ; rlwimi     r0,r9,24,0,7
8001E960: 39400002  li       r10,2
8001E964: 39200003  li       r9,3
8001E968: 38800004  li       r4,4
8001E96C: 5143C00E  insrwi   r3,r10,8,0              ; rlwimi     r3,r10,24,0,7
8001E970: 5127C00E  insrwi   r7,r9,8,0               ; rlwimi     r7,r9,24,0,7
8001E974: 5088C00E  insrwi   r8,r4,8,0               ; rlwimi     r8,r4,24,0,7
8001E978: 48000024  b        *+36                    ; 0x8001E99C
8001E97C: 3D000166  lis      r8,358
8001E980: 3C600266  lis      r3,614
8001E984: 3CE00366  lis      r7,870
8001E988: 3C800466  lis      r4,1126
8001E98C: 38086666  addi     r0,r8,26214
8001E990: 38636666  addi     r3,r3,26214
8001E994: 38E76666  addi     r7,r7,26214
8001E998: 39046666  addi     r8,r4,26214
8001E99C: 3D20CC01  lis      r9,-13311
8001E9A0: 39400061  li       r10,97
8001E9A4: 99498000  stb      r10,-32768(r9)
8001E9A8: 2C050000  cmpwi    r5,0x0000
8001E9AC: 38800053  li       r4,83
8001E9B0: 39600000  li       r11,0
8001E9B4: 90098000  stw      r0,-32768(r9)
8001E9B8: 38000054  li       r0,84
8001E9BC: 39800000  li       r12,0
8001E9C0: 508BC00E  insrwi   r11,r4,8,0              ; rlwimi     r11,r4,24,0,7
8001E9C4: 99498000  stb      r10,-32768(r9)
8001E9C8: 500CC00E  insrwi   r12,r0,8,0              ; rlwimi     r12,r0,24,0,7
8001E9CC: 90698000  stw      r3,-32768(r9)
8001E9D0: 99498000  stb      r10,-32768(r9)
8001E9D4: 90E98000  stw      r7,-32768(r9)
8001E9D8: 99498000  stb      r10,-32768(r9)
8001E9DC: 91098000  stw      r8,-32768(r9)
8001E9E0: 41820040  beq      *+64                    ; 0x8001EA20
8001E9E4: 88860000  lbz      r4,0(r6)
8001E9E8: 88060004  lbz      r0,4(r6)
8001E9EC: 508B06BE  insrwi   r11,r4,6,26             ; rlwimi     r11,r4,0,26,31
8001E9F0: 88660001  lbz      r3,1(r6)
8001E9F4: 500C06BE  insrwi   r12,r0,6,26             ; rlwimi     r12,r0,0,26,31
8001E9F8: 88A60002  lbz      r5,2(r6)
8001E9FC: 506B3532  insrwi   r11,r3,6,20             ; rlwimi     r11,r3,6,20,25
8001EA00: 88660005  lbz      r3,5(r6)
8001EA04: 88860003  lbz      r4,3(r6)
8001EA08: 50AB63A6  insrwi   r11,r5,6,14             ; rlwimi     r11,r5,12,14,19
8001EA0C: 88060006  lbz      r0,6(r6)
8001EA10: 506C3532  insrwi   r12,r3,6,20             ; rlwimi     r12,r3,6,20,25
8001EA14: 508B921A  insrwi   r11,r4,6,8              ; rlwimi     r11,r4,18,8,13
8001EA18: 500C63A6  insrwi   r12,r0,6,14             ; rlwimi     r12,r0,12,14,19
8001EA1C: 48000020  b        *+32                    ; 0x8001EA3C
8001EA20: 38600015  li       r3,21
8001EA24: 556B0026  clrrwi   r11,r11,12              ; rlwinm     r11,r11,0,0,19
8001EA28: 506C06BE  insrwi   r12,r3,6,26             ; rlwimi     r12,r3,0,26,31
8001EA2C: 38000016  li       r0,22
8001EA30: 506B63A6  insrwi   r11,r3,6,14             ; rlwimi     r11,r3,12,14,19
8001EA34: 500B921A  insrwi   r11,r0,6,8              ; rlwimi     r11,r0,18,8,13
8001EA38: 558C069A  rlwinm   r12,r12,0,26,13
8001EA3C: 3C80CC01  lis      r4,-13311
8001EA40: 38A00061  li       r5,97
8001EA44: 98A48000  stb      r5,-32768(r4)
8001EA48: 38000000  li       r0,0
8001EA4C: 806280D0  lwz      r3,-32560(r2)
8001EA50: 91648000  stw      r11,-32768(r4)
8001EA54: 98A48000  stb      r5,-32768(r4)
8001EA58: 91848000  stw      r12,-32768(r4)
8001EA5C: B0030002  sth      r0,2(r3)
8001EA60: 4E800020  blr

http://class.ece.iastate.edu/arun/C...0a_Files/PowerPC Assembly Quick Reference.htm

I believe register 5 is the one that corresponds to its third argument, based on an observation of compiling two .elf's, one calling it with 3rd arg as GX_TRUE and another as GX_FALSE, and they were 38A00001 and 38A00000 respectively after diffing the files (A0 is register 5, apparently: 38A00061 li r5,97)

 

[NoobletCheese]

2C050000  cmpwi    r5,0x0000
...
8001E9E0: 41820040  beq      *+64                    ; 0x8001EA20

^ appears to be branching ahead 64 bytes if reg5 is 0 (i.e if vf = GX_FALSE).

So we can change it to always branch:

48000040  b        *+64

i.e in main.dol change:

2C 03 00 00 41 82 00 F8 89 04 00 00 38 00 00 00 89 44 00 01 38 60 00 00 51 00 07 3E 88 E4 00 06 51 40 26 36 89 04 00 0C 50 E3 07 3E 38 E0 00 00 51 07 07 3E 89 44 00 0D 89 64 00 07 39 00 00 00 51 47 26 36 89 44 00 02 89 24 00 12 51 63 26 36 51 40 45 2E 89 44 00 0E 51 28 07 3E 89 24 00 13 51 47 45 2E 89 44 00 03 51 28 26 36 89 24 00 14 51 40 64 26 89 44 00 0F 51 28 45 2E 89 24 00 15 51 47 64 26 89 44 00 04 89 64 00 08 51 28 64 26 51 40 83 1E 89 44 00 10 89 24 00 16 51 63 45 2E 89 64 00 09 51 47 83 1E 89 44 00 05 51 28 83 1E 89 24 00 11 51 63 64 26 89 64 00 0A 51 40 A2 16 89 44 00 0B 51 27 A2 16 88 84 00 17 39 20 00 01 51 63 83 1E 51 43 A2 16 50 88 A2 16 51 20 C0 0E 39 40 00 02 39 20 00 03 38 80 00 04 51 43 C0 0E 51 27 C0 0E 50 88 C0 0E 48 00 00 24 3D 00 01 66 3C 60 02 66 3C E0 03 66 3C 80 04 66 38 08 66 66 38 63 66 66 38 E7 66 66 39 04 66 66 3D 20 CC 01 39 40 00 61 99 49 80 00 2C 05 00 00 38 80 00 53 39 60 00 00 90 09 80 00 38 00 00 54 39 80 00 00 50 8B C0 0E 99 49 80 00 50 0C C0 0E 90 69 80 00 99 49 80 00 90 E9 80 00 99 49 80 00 91 09 80 00 41 82 00 40

to

2C 03 00 00 41 82 00 F8 89 04 00 00 38 00 00 00 89 44 00 01 38 60 00 00 51 00 07 3E 88 E4 00 06 51 40 26 36 89 04 00 0C 50 E3 07 3E 38 E0 00 00 51 07 07 3E 89 44 00 0D 89 64 00 07 39 00 00 00 51 47 26 36 89 44 00 02 89 24 00 12 51 63 26 36 51 40 45 2E 89 44 00 0E 51 28 07 3E 89 24 00 13 51 47 45 2E 89 44 00 03 51 28 26 36 89 24 00 14 51 40 64 26 89 44 00 0F 51 28 45 2E 89 24 00 15 51 47 64 26 89 44 00 04 89 64 00 08 51 28 64 26 51 40 83 1E 89 44 00 10 89 24 00 16 51 63 45 2E 89 64 00 09 51 47 83 1E 89 44 00 05 51 28 83 1E 89 24 00 11 51 63 64 26 89 64 00 0A 51 40 A2 16 89 44 00 0B 51 27 A2 16 88 84 00 17 39 20 00 01 51 63 83 1E 51 43 A2 16 50 88 A2 16 51 20 C0 0E 39 40 00 02 39 20 00 03 38 80 00 04 51 43 C0 0E 51 27 C0 0E 50 88 C0 0E 48 00 00 24 3D 00 01 66 3C 60 02 66 3C E0 03 66 3C 80 04 66 38 08 66 66 38 63 66 66 38 E7 66 66 39 04 66 66 3D 20 CC 01 39 40 00 61 99 49 80 00 2C 05 00 00 38 80 00 53 39 60 00 00 90 09 80 00 38 00 00 54 39 80 00 00 50 8B C0 0E 99 49 80 00 50 0C C0 0E 90 69 80 00 99 49 80 00 90 E9 80 00 99 49 80 00 91 09 80 00 48 00 00 40

This is working for Battalion Wars 2.

edit: I also tried the other option of changing:

2C050000 cmpwi r5,0x0000
to
2C050001 cmpwi r5,0x0001

i.e branch if vf = GX_TRUE, but the game crashes on boot.

Also it may be better better to branch regardless, otherwise games that don't set a vfilter would cause them to do the opposite and set the vfilter on.

 

[NoobletCheese]

Just to note that in ULGX, pressing HOME > Reset reloads the game without 'use alternate DOL' so you lose the patch.

edit: it seems some games just go back to the title screen on Reset instead of rebooting the whole executable and shouldn't lose the patch.