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

[NoobletCheese]

what about using the open homebrew channel which is already in wad form?

According to Dolphin there is no vfilter on Open Homebrew Channel (toggling copy filter shows no change in pixels).

If Dolphin is set to 480i by unticking progressive scan, then yes the vfilter is present and togglable with the copy filter checkbox.

This matches what I observe on the Wii console.

So I'm not sure why MaeseJesus is seeing a soft image -- perhaps they could take a screenshot on the About screen (which features white text on black background and should reveal any filtering).

Once the next update goes live, I'm assuming there won't be any point in hex editing ULGX's boot.dol, right?

To my knowledge blackb0x has not made any modifications to remove the vfilter for the ULGX GUI which is only present when it's running in 480i mode. Games can all be patched however you like though.

 

[SaulFabre]

The range used for gecko codes starts at 80001800 is about 4 KB. Aside from that, all games have the same debug strings (if a different address each game is no problem) you could probably use these spots to safely fit small info. Some of my codes do this to make identification easier. E.g. the string "! ! ! C A U T I O N ! ! !" is in every game I've messed with.

Well @SuperrSonic, i have questions... do you know how to do that procedure of increasing brightness in NES VC games work on a real Wii console? And how I can "convert" (turn) a Gecko code into hex values and how to know what is the correct offset for "insert" the "converted" Gecko code to hex code (hex values) in the uncompressed 00000001.app?

So I still think because of the VC emulator's NES darkened color pallete.

Do you have idea about this?

 

[kingjinxy2]

This code should work on all popular system menus, but it has only been tested on the 4.2U version.
It's been a long time but I think all you need to do is delete the hacks file installed (I used wiixplorer) and replace it with the new one.

[Remove Deflicker]
maxversion=518
minversion=288
amount=5
hash=0x0608080a,0x0C0A0808
patch=0x06000015,0x16150000
hash=0x0608080a,0x0C0A0808
patch=0x06000015,0x16150000
hash=0x0608080a,0x0C0A0808
patch=0x06000015,0x16150000
hash=0x0608080a,0x0C0A0808
patch=0x06000015,0x16150000
hash=0x0608080a,0x0C0A0808
patch=0x06000015,0x16150000

You might not care about this detail but injecting SMB3 in other VC emulators does produce some graphical glitches missing from the official release. I didn't test every VC of course so maybe I was unlucky but the same bugs appear in the Animal Crossing emulator.

This is incredible! I can't wait for the USB Loader GX release!

 

[SuperrSonic]

Well @SuperrSonic, i have questions... do you know how to do that procedure of increasing brightness in NES VC games work on a real Wii console? And how I can "convert" (turn) a Gecko code into hex values and how to know what is the correct offset for "insert" the "converted" Gecko code to hex code (hex values) in the uncompressed 00000001.app?

So I still think because of the VC emulator's NES darkened color pallete.

Do you have idea about this?

No idea, but I can confirm NoobletCheese's patch works perfectly for SNES games on a real Wii. What you're asking is difficult to explain, the codes are already in hex, it depends on the type of code to be able to "convert" it and write it permanently and I simply don't know enough about the subject, I just learn what I need to make my codes. Luckily we don't have to convert codes, we can embed them using wstrt if all else fails.

These don't see a big change compared to NES games but is still nice to have, here they are in gecko code form:

Super Mario All-Stars SVME01

Restore Brightness 0x1F
06036578 00000078
2c050001 38800053
39600000 90098000
38000054 39800000
508bc00e 99498000
500cc00e 90698000
99498000 90e98000
99498000 91098000
41820040 38800000
38000015 508b06be
38600000 500c06be
38a00015 506b3532
38600000 3880001f
50ab63a6 38000000
506c3532 508b921a
500c63a6 48000020

Apply blurry filter (no practical use, just found it by chance)
00165193 00000001

Secret of Mana JCLE

Restore Brightness 0x1F
0602f678 00000078
2c050001 38800053
39600000 90098000
38000054 39800000
508bc00e 99498000
500cc00e 90698000
99498000 90e98000
99498000 91098000
41820040 38800000
38000015 508b06be
38600000 500c06be
38a00015 506b3532
38600000 3880001f
50ab63a6 38000000
506c3532 508b921a
500c63a6 48000020

 

[blackb0x]

Once the next update goes live, I'm assuming there won't be any point in hex editing ULGX's boot.dol, right?

Most people who want the best quality picture are already using 480p, so the loader won't apply a deflicker filter. And for that reason I won't be modifying libogc or patching the dol file.

I can't wait for the USB Loader GX release!

I'd like to say that it'll be soon, but every time I say that someone asks for another feature or reports a bug and then I've got to delay things again.

Progress is slow right now because someone from Korea reported a bug that I can't reproduce. So I'm working with them to diagnose and fix the problem, but every time I send them a message I might not get a reply for a day or two.

 

[NoobletCheese]

@SaulFabre @Zorg1996

Re: VC NES game brightness

I observe:

• Patching 00001516150000 instead of 00001530150000 is working on Wii console
• Patching 00001518150000 is working (brightness + 2 steps)
• Patching 0000151A150000 is not working (brightness + 4 steps)
• Patching 08080A0C0A0808 is not working (Wii system menu vfilter)

It appears the patching method is functional, but the game requires 00001516150000 for some reason.

I speculate it may related to the pixel format used by these NES games. Maybe the pixel format is incompatible for multiplication with vfilter coefficients, causing the colour values to become out of range.

If you recall here I was mucking around with the pixel format in Resident Evil 4, so we could try to change the pixel format of these NES VC games.

btw I also tried a different GXSetCopyFilter patching method where at the start of function I set up the registers as they would be if the game had called it normally with no null arguments:

GXSetCopyFilter(aa, sample_pattern, vf, vfilter)

Set aa and sample_pattern
38600000  li       r3,0               ; aa = GX_FALSE
3C808000  lis      r4,0x8000          ; sample_pattern = 0x80002354 high order bits
60842354  ori      r4,r4,0x2354       ; sample_pattern = 0x80002354 low order bits

Set vf and vfilter
38A00001  li       r5,1               ; vf = GX_TRUE
3CC08000  lis      r6,0x8000          ; vfilter = 0x800023B8 high order bits
60C623B8  ori      r6,r6,0x23B8       ; vfilter = 0x800023B8 low order bits

Load vfilter coefficients into vfilter address
38600000  li       r3,0x00
98660000  stb      r3,0(r6)           ; 0x800023B8 = 0x00
38600000  li       r3,0x00
98660001  stb      r3,1(r6)           ; 0x800023B9 = 0x00
38600015  li       r3,0x15
98660002  stb      r3,2(r6)           ; 0x800023BA = 0x15
38600030  li       r3,0x30
98660003  stb      r3,3(r6)           ; 0x800023BB = 0x30
38600015  li       r3,0x15
98660004  stb      r3,4(r6)           ; 0x800023BC = 0x15
38600000  li       r3,0x00
98660005  stb      r3,5(r6)           ; 0x800023BD = 0x00
38600000  li       r3,0x00
98660006  stb      r3,6(r6)           ; 0x800023BE = 0x00
38600000  li       r3,0x00            ; aa = GX_FALSE (since we just used this reg and need to reset it)
60000000  no-op                       ; just some extra space left over
60000000  no-op
60000000  no-op

Branch to section after aa setting is complete (which is normally skipped anyway)
480000A8  b        *+168

Again, the above code is working on Dolphin but not Wii console.

So I don't believe it's an issue with the patching method, but more likely the game's rendering mode is just not compatible with vfilter.

 

[NoobletCheese]

I notice when these NES VC games are running in 480i mode there is no vfilter either.

It's quite unusual for a game to have no vfilter in 480i mode -- perhaps the devs intentionally disabled it due to this known incompatibility which we are currently observing.

The only reason I know of is this bit from the SDK:

Note that although a three-line filter is used for deflickering, only a single-line filter must be used during field rendering

Single-line filter = 00001516150000 (which can be successfully patched).

Now you might say 00001530150000 is also a single line filter, but then this bit:

It is possible to change the overall screen brightness by making the sum total of the coefficients a value other than 64, but depending on color values this could cause overflow and lead to display problems.

So there is no guarantee that pushing them beyond 64 won't cause these kinds of issues.

But back to the issue of field rendering... I noticed the game's GXRenderModeObj's are all set to field_rendering=true for interlace modes and false for progressive modes, which are the expected values. However we know games don't always use the values inside GXRenderModeObjs and may set them explicitly elsewhere.

So for now my focus will be on trying to get these NES games to use field_rendering=false, and then hopefully our custom vfilter will work. Given the aforementioned observation this will probably require patching VIConfigure or GXSetFieldMode...

 

[Maeson]

It's kinda frustrating to see what a headache the NES VC is giving you, knowing homebrew emulators are so much better all around, one could just make forwarder-like channels for quick access to specific games if having them accessible from the Wii Menu is the desired thing... Or at least I think you can, I remember seeing something like that.

We are very lucky that the N64 titles do support 480p right out of the gate. There was pretty wide support for 240p, but why would anyone play NES games on 480i without extra features VS 480p with a gigantic array of options...

By the way, I dumped my HBC, and the resulting wad had nothing recognizable as a video filter. 01.app is tinny and uncompressed. So I'll leave it at that.

 

[SaulFabre]

Too bad for the official NES games released as Virtual Console games for Wii

But, anyone have sucess with brightening the NES Wii VC games which works also in real Wii console, with another method or something?

 

[SaulFabre]

Any progress on brightening NES VC games on Wii???

 

[SunkenSkunk]

Howdy! Just KO'd the NES VC palette issue today-- it's mildly off topic but I'll keep it concise since there's demand for it.
The actual palette is stored as RGB5A3, 0x80 bytes long, and starts with 'A529 800D 840C 940B' (for a few games I checked, anyway)
For reference, in SMB2 USA the loop mapping palette ram => colors is at 0x8000F18C, and the default palette is at 0x80163BB0 (offset 0x15FCB0). Might be useful if any extra research is required-- though it really shouldn't be.
I've attached a python script to convert your favorite NES palettes to VC's format, ready to be pasted over or turned into a cheat code. If you don't want to use that, or need a quick reference, here's FirebrandX's 'Composite Direct' palette pre-formatted:

Spoiler

B18C804F8C119810A80BAC03A4009C608CC080E0810080E280AA800080008000D6B58D39A0BCB47AC875CC6BCCC0BD20AD8091E0820081E781B1800080008000FFFFB2BFC63FD9DFF1BFF5B8FA0DEE65DEC1C321AF47A74FA719A52980008000FFFFE39FEF7FF75FFF3FFF3EFF59FF76F7B4EBD4E3F7DFDADFDEDEF780008000

Conversion script (Python3, supports drag-n-drop):

Spoiler

#!/usr/bin/python3
import os, sys, argparse, struct


def main(ext_args = None):
    parser = argparse.ArgumentParser(description='Convert a NES .pal palette to Virtual Console RGB5A3 format.')
    parser.add_argument('fn_input', metavar='input',
        help='Input .pal palette file, will output to [file.pal].bin')
    args = parser.parse_args(ext_args) # if == None, will decay to sys.argv
   
    fn_input = os.path.normpath(args.fn_input)
    fn_output = fn_input + '.bin'
   
    palette = bytearray()
    with open(fn_input, 'rb') as f:
        palette = f.read()
   
    vc_palette = bytearray()
    for i in range(64):
        # get values and shift them down to 5 bits
        r = palette[(i*3) + 0] >> 3
        g = palette[(i*3) + 1] >> 3
        b = palette[(i*3) + 2] >> 3
        vc_palette +=  struct.pack(">H", (1<<15) | (r << 10) | (g << 5) | b)
   
    print("VC palette (hex string):")
    print(vc_palette.hex())
   
    with open(fn_output, 'wb') as f:
        f.write(vc_palette)
   

    print('Successfully completed!')
   
if __name__ == '__main__':
    main()

Full research process for the curious-- it's more accessible than you might think:

Spoiler

I took a few stabs at finding RGB888 => RGB565 converted values at first, to find the palette directly, but didn't have any luck. (This makes sense as it turned out to be RGB5A3)
Next, I decided to find palette ram => color mapping happening in the emulator. I booted up a debugging NES emu, noted some of the current palette bytes, and searched for that in a Wii VC ram dump.
I found three instances-- one which was within the bounds of the rom, another which matched that section of the ROM entirely, and a third which didn't. I suspected the third was the palette ram, so with Dolphin I put a breakpoint-on-memory-read on its first bytes. This led to finding the palette mapper func, and without even unpausing the debugger I was able to find the active palette buffer from there. Finally a simple search for this palette in the binary itself was needed, since it was in a non-static buffer, to ensure it wasn't transformed/crushed on the fly-- which it isn't.

 

[NoobletCheese]

@SunkenSkunk

Great stuff, I can confirm it is working on both Dolphin and Wii hardware

Firebrandx's "composite direct" palette appears to be an authentic palette captured from original NES hardware which uses the full dynamic range and isn't darkened. So this appears to be the faithful to the original colours on NES, and would be the best way to correct the issue imo.

edit: unless you don't want to emulate composite video colours, in which case a 'passthrough' type palette might be preferable -- is this possible?

 

[NoobletCheese]

[deleted - contains incorrect information]

 

[Zorg07]

@SunkenSkunk

Great stuff, I can confirm it is working on both Dolphin and Wii hardware

Firebrandx's "composite direct" palette appears to be an authentic palette captured from original NES hardware which uses the full dynamic range and isn't darkened. So this appears to be the faithful to the original colours on NES, and would be the best way to correct the issue imo.

Really? That is great, I would like to do it on my own but I have no knowledge of phyton. If you could @NoobletCheese help me I would be grateful.

 

[NoobletCheese]

Really? That is great, I would like to do it on my own but I have no knowledge of phyton. If you could @NoobletCheese help me I would be grateful.

In 01.app find
A529800D840C940Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Replace with
B18C804F8C119810A80BAC03A4009C608CC080E0810080E280AA800080008000D6B58D39A0BCB47AC875CC6BCCC0BD20AD8091E0820081E781B1800080008000FFFFB2BFC63FD9DFF1BFF5B8FA0DEE65DEC1C321AF47A74FA719A52980008000FFFFE39FEF7FF75FFF3FFF3EFF59FF76F7B4EBD4E3F7DFDADFDEDEF780008000

x = wildcard, may vary between games

edit: although if different games are using different palettes to begin with, replacing them all with the same palette would result in wrong colours. In that case the best option may be to modify the game's original palette to increase the peak brightness only. eg. export palette from game's 01.app, then increase brightness using a tool like this http://drag.wootest.net/misc/palgen.html , then import it back into 01.app.

 

[SuperrSonic]

Working here in code form. Using the original palette as base, and applying exposure 1.07 with PS.

The waterfalls in the starting level of SMB2 are not affected by the palette, this should be expected considering that if you take the rom and try it on other emulators it uses one of the blank colors.

Super Mario Bros. 3 NTSC-U

Restored brightness palette
061e0bd0 00000080
b18c8012 88119c0f
ac0db000 ac009c60
90c08102 810080e2
80ab8000 80008000
d2748117 a01eb419
c415c80a c8a0bd00
ad8091e0 89e081e8
818f8842 80008000
fbdeb67f c5ffdddf
f1def997 fe2de668
d687bee0 a708a30f
ab18a529 80008000
ffffe37f e31eef1f
f6fffb1b fb58ef35
ef74e7b5 dfb5d777
d358ef7b 80008000

Widescreen Correction using VI
281c7cea 00000028
021c7cea 00000068
021c7cee 00000200
021c7cea 00000068
021c7cee 00000200
021c7d62 00000068
021c7d66 00000200
e0000000 80008000

No DF in HOME Menu/eManual
061c7e02 00000007
00001516 15000000
061c7e7a 00000007
00001516 15000000
061c7ef2 00000007
00001516 15000000
061c7f6a 00000007
00001516 15000000

 

[NoobletCheese]

Using the original palette as base, and applying exposure 1.07 with PS

How did you convert between palette and image file — are there some tools available?

 

[NoobletCheese]

@SuperrSonic

Also which version of Dolphin are you using to take your screenshots? I'm using the latest version and can't get the pixel perfect edges seen in your screenshots. For example the black to white pixels in the checkerboard pattern at bottom of SMB3 title, life number in Metroid, or Mega Man 9 vertical life bar, the transition still has filtering in Dolphin as if the vfilter is still active (even though it's definitely not) or the framebuffer is being scaled slightly causing that loss of 1:1 pixel mapping.

I tried everything: all settings in Dolphin, with or without your aspect ratio patches, none of it can produce the pixel perfect raster that your screenshots show. I am now starting to suspect it's an issue with my GPU driver (switching between OpenGL/DX/Vulcan doesn't affect it either though).

I can fix it in either the horizontal direction or vertical direction (but not both) by manually adjusting the Dolphin window size until it "snaps" to pixel perfect edges, but only in one direction (horizontal or vertical, one of them will still have imperfect pixel edges). Auto window size has the issue too, so maybe it's a bug with Dolphin's window size setting? Or maybe GPU driver is rounding the raster size slightly incorrectly?

 

[SuperrSonic]

How did you convert between palette and image file — are there some tools available?

Nothing fancy, a long time ago I asked about injecting a NES homebrew tool that displays the palette on screen for the purpose of ripping the VC palette to a file. Someone used a usb gecko to take (essentially) perfect screenshots and posted them, then I used those screenshots to write each color into a file. I experimented until I found acceptable settings, and once again patiently wrote it into a palette file. This file is what I used with SunkenSkunk's tool to make the code so quickly.

The SMB3 screenshots are really texture dumps. The Mega Man shots were regular dolphin screenshots, the window size did need to match the game's but I don't know if that behavior has changed in other dolphin versions. Do you have "Stretch to Window" selected? Since the other options seem to imply messing with the native size.

 

[NoobletCheese]

Do you have "Stretch to Window" selected? Since the other options seem to imply messing with the native size.

I've tried that without success, and it wouldn't be a viable solution anyway since the 'auto adjust window size' doesn't work when 'stretch to window' is selected, so I've got to spend a long time manually adjusting the window size for each game until pixels finally "snap" to 1:1 which I couldn't get it to do anyway.