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

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
Just a technical note: for each game I think it's definitely worth patching all found vfilters, and upload all their offsets to the cloud. So I will put all of MaeseJesus's data into the cloud, not just the ones which we think the game uses.

The reason is because there could be some cases where the game sets a different vfilter depending on whether the console is outputting 480i vs 480p, or perhaps different parts of the game set different filters. It also eliminates the issue of having to do a lot of trial-and-error to find the one the game uses, before it can be added to the cloud.

USB Loaders are then free to patch all offsets stored in the cloud, or even use their own rules about which filters they think are worth patching or not. In any case, more data in the cloud is better than less data.

Also just a progress update on the tool development: I've completed the main 'find vfilters' function and tested it quite rigorously, inserting dummy data into .dols and checking the threshold for false positive is being met. The GUI has been completed too, so I can now begin working on the main 'patch file' function. This is the scariest one because it must not make any mistakes, otherwise the consequences could be potentially disastrous. eg. writing some wrong bytes might happen to be some instruction for writing some data to sysNAND and brick the console! However it's fairly easy to test for corruption as in HxD we can use Analysis > Data Comparison > Compare vs the original file and make sure it only patched exactly what we told it to.
 
Last edited by NoobletCheese,

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
On my PC I'm noticing some bugs with HxD. Sometimes after I search, I get an infinite number of error popups saying "table index out of range" or something, after which it no longer finds results when searching. I'm not sure if this is my PC's fault, but thought I should mention it as it could corrupt DOLs. I am working around it by restarting HxD after every time I do a search or replace.

To anyone wondering about this whether it will corrupt your DOLs, it appears to be a benign bug which only affects the display of search results, and will be fixed in the next version according to the developer of HxD:

https://forum.mh-nexus.de/viewtopic.php?f=3&t=1152

How to trigger the bug with a DOL:

1. Find all hex 060606060606060606060606060606060606060606060606
2. Replace all hex 060606060606060606060606060606060606060606060606 with 03020906030A03020906030A09020306090A09020306090A
3. Move mouse cursor into the search results window at the bottom, and the error message should pop up "list index out of bounds"
 
  • Like
Reactions: XFlak

Maeson

Well-Known Member
Member
Joined
Apr 3, 2013
Messages
1,180
Trophies
1
XP
3,387
Country
Spain
The errors I have got with HxD never affected the files I edited, for what that's worth.

Here are a few more:

Code:
Resident Evil 4: Wii Edition 
RBP08    Warning:    Picture clears up, but this game 
PAL                    uses Dithering, so depending on the 
                    lighting it might be more noticeable.
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    2D3A9A
                            2D3B12
                            2F2742
                            2F277E
                            2F27BA
                            2F27F6
                            30EC78
                           
Resident Evil Archives: Zero 
RBHP08    PAL
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    3C8036
                            3CC142
                            3CC1BA
                            3CC1F6
                            3CC26E
    04 08 0C 10 0C 08 04    3C8072
   
Resident Evil Archives: Remake
RE4P08    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    33FF9A
                            3B8FBE
                            3BD162
                            3BD19E
                            3BD1DA
                            3BD216
                            3D6F70 > No string before it. 
    04 08 0C 10 0C 08 04    3B8FFA
                           
   
Resident Evil: Umbrella Chronicles
RBUP01    PAL
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    423B22
                            423D3E
                            423F5A
                            4240FE
                            436A70 > No string before it.
    04 08 0C 10 0C 08 04    4241EE
   
Bakugan: Battle Brawlers
RUHX52    NTSC - Toys R Us Version 
    VFilter:                Offsets 
    08 08 0A 0C 0A 08 08    3DCA56
                            3E0D6A
                            3E0DE2
                            3E0E1E
                            3E0E96
                            3E0ED2
                            3E0F0E
                            3E0F86
    04 08 0C 10 0C 08 04    3DCA92
   
Link's Crossbow Training
RZPP01    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    2A55A2
                            2A55DE
                            2A461A
                            2D88AA
                            2D8922
                            2D895E
                            2D899A

Disaster: Day of Crisis
RDZP01                    THIS IS INCOMPLETE!
                        I lost the unmodified main.dol
                        and I need to rip my disc again.
                        Ugh...
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    5BD4F8    > No string before it. 
                           
    04 08 0C 10 0C 08 04
   
Geometry War: Galaxies   
RGLP7D    PAL
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    1FE44A
                            1FE486
                            1FE4C2
                            217D42
                            217D7E
                            217DBA
                            217DF6
                       
Ghost Squad
RGSP8P    PAL
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    4D2662
                            4D269E
                            4D26DA
                            4D2716
                            4D2752
                            4D278E
                            4D27CA
                           
Sin & Punishment 2: Successor of the Skies 
R2VP01
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    32EB4E
                            3329D2
                            332A86
                            332AC2
                            332B3A
    04 08 0C 10 0C 08 04    32EB8A
                           
Dragon Ball Z: Budokai Tenkaichi 2
RDBE70    NTSC US     PAL Does not have 60Hz modes. 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    3A76E2
                            3A775A
                            3A7796
                            3A77D2
                            3A780E

Dragon Ball Z: Budokai Tenkaichi 3
RDSE70    NTSC US        PAL Does not have 60Hz modes. 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    38C362
                            38C39E
                            38C3DA
                            38C416
                            38C452

Super Monkey Ball: Step & Roll 
SMBP8P    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    4574AE
                            4678B2
                            46792A
                            4679A2
                            4679DE
    04 08 0C 10 0C 08 04    4574EA
   
Super Monkey Ball: Banana Blitz 
RSMP8P    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    297A5A
                            297AD2
                            297B4A
                            297B86
                           
Centipede Infestation
SCPE70    NTSC US        No PAL Release.
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    4D885E
                            4D963A
                            4D96B2
                            4D96EE
                            4D972A
    04 08 0C 10 0C 08 04    4D889A

I need to dump Disaster again... Kinda annoying.
 

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
The program is named wwcxtool.exe, I got it long time ago somewhere here in gbatemp.

It is a command line tool, so you need to know how to use it. On the folder you have the tool and 00000001.app I type cmd on the browser on the top and it will open it.

The command goes like this:

wwcxtool /u 00000001.app NameOfUncompressedfile.app

Then, to compress it back again after modified:

wwcxtool /c1 NameOfUncompressedfile.app 00000001.app

And that's how I do it. Not every Wiiware game has a compressed 01.app, if it's over 2.5mb or larger the chances of being compressed are slim, and you can edit those from the get-go.

Since wwcxtool is a command line utility, I'm considering automating this in my GUI tool for convenience.

However I'm unsure what should happen next to the patched and re-compressed .app file -- do we have to repack it back into the WAD, or just save it as [gameID].dol and point USB Loader to it?

I have zero knowledge of how Wiiware games are loaded :blush:
 

Maeson

Well-Known Member
Member
Joined
Apr 3, 2013
Messages
1,180
Trophies
1
XP
3,387
Country
Spain
The option to load external dol does not show up on USB Loader GX with downloadable games as far as I've seen. Meaning, once the 00000001.app is modified, it has to be re-compressed again with wwcxtool (if it's needed), put back on the folder created with the uncompressed .wad file and recreate the .wad file.

That's what I've done with all my Wiiware games. I haven't seen any change on VC games (at least, N64, which are the only VC releases I use) so it's not necessary to waste time with those.
 
  • Like
Reactions: NoobletCheese

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
once the 00000001.app is modified, it has to be re-compressed again with wwcxtool (if it's needed), put back on the folder created with the uncompressed .wad file and recreate the .wad file.

Cheers, I'm playing around with it now (wwpacker) and it seems to be automatable with batch files.

So my tool should be able to take a .wad as an input file, modify vfilters, and produce a patched .wad output file.

However when rebuilding the wad, which _wwpacker.bat are you running -- _wwpacker-NoMod.bat? ("No Modification, just packing" according to the readme file).

Sidenote: it seems to require common-keys.bin which I cannot distribute with my tool for legal reasons, however Wii Scrubber can generate one so user can be informed if they select wad as the input file.
 
Last edited by NoobletCheese,

Maeson

Well-Known Member
Member
Joined
Apr 3, 2013
Messages
1,180
Trophies
1
XP
3,387
Country
Spain
Actually, using wwcxtool.exe by itself requires no common-key.bin. You can isolate the exe to its own folder and it will work by itself. I used it manually to edit all the 01.apps of the WiiWare games I have with it and I don't have common-key.bin.

And yes, Wii Scrubber is an easy way to create such file.
 

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
Actually, using wwcxtool.exe by itself requires no common-key.bin. You can isolate the exe to its own folder and it will work by itself. I used it manually to edit all the 01.apps of the WiiWare games I have with it and I don't have common-key.bin.

So you were able to extract and repack 01.app to the wad without common-key.bin?

According to what I have read, that is not possible, but please correct me if I'm wrong.

I am trying to automate the whole process so the user doesn't have to do all the command line extracting and repacking.

But I am having second thoughts, because if the wad doesn't get repacked properly, it could brick the user's console and I don't want to be responsible.

edit: actually I remember reading about how USB Loader GX can load wad's in a safe way from emuNAND or something...so maybe I will go ahead with it and just warn the user to do it the safe way.
 
Last edited by NoobletCheese,

Maeson

Well-Known Member
Member
Joined
Apr 3, 2013
Messages
1,180
Trophies
1
XP
3,387
Country
Spain
Well, I just tried again. On an empty folder with just wwcxtool and a random 00000001.app, I ran cmd and wrote the command to decompress the app file. It worked no issue. I made it compress it and again, worked just fine.

About the other matter, I don't know, I personally wouldn't make the entire process automated. It's very easy to use ShowMiiWads to unpack a wad to a folder, and just take the 00000001.app, maybe then use your tool, and bring back the modified app back to its folder and use ShowMiiWads again to pack it to a wad again. I personally don't find modifying the files myself, but of course not everybody knows these things.

I completely get you, Wads can be risky, and no one wants to be responsible for what might happen. With that said though, a bad wiiware/vc wad shouldn't be that hard to fix, if you can boot to homebrew channel, you could use YAWMM to uninstall it quickly. Heck, if the wad doesn't have modified banners (that's what causes most of the bricks with these things) I think you could still use the Wii Menu normally.

EmuNand can be used for a big list of Wiiware and VC games so you don't have to use your real nand, I tried most of the games I edited with it, they worked as intended, just without filters (except, again, purely 2D games which seem to not use any at all). It won't work with every game, but if you still don't want to use your real nand, you still can use sneek and uneek, which are simulated Wii Menus with the possibility to install games on them, and the games that won't work on USB Loader's GX Emunand usually work on sneek/uneek.

I think the best approach would be informing the user of all these things, that they make sure the Wads they edit work before installing into the real nand, and to make backups of it before doing anything. At the end of the day though, you can only do so much as far as protect others from their own stupidity. If they don't read the readmes, guides, or just pay attention to warnings, it should be their fault and not yours.


Now that I've spent a few days playing without filters, I have to say... It didn't seem like much difference when I started, but now changing between filtered and unfiltered makes a really big difference to me.
 

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
About the other matter, I don't know, I personally wouldn't make the entire process automated. It's very easy to use ShowMiiWads to unpack a wad to a folder, and just take the 00000001.app, maybe then use your tool, and bring back the modified app back to its folder and use ShowMiiWads again to pack it to a wad again. I personally don't find modifying the files myself, but of course not everybody knows these things.


I'd probably agree with you there.

I mean, the user already has to do a bit of file pushing to set up USB Loader to run the patched dol.

And patching only the dol instead of patching the entire wbfs/iso is still the most convenient method imo, as it avoids additional time and data overhead of backing up and re-writing ~5GB per game.

With Gamecube games it's also faster to re-insert the patched Start.dol into the iso using the tool GCR, because unlike WIT, GCR doesn't have to rebuild the entire iso from scratch — it appears to overwrite only the relevant bytes inside the iso.


Now that I've spent a few days playing without filters, I have to say... It didn't seem like much difference when I started, but now changing between filtered and unfiltered makes a really big difference to me.

The word I would use to describe these kinds of video filters is insidious.

i.e harmful but in a subtle way that gradually ruins the experience.

I have experienced similar issues with video filters in other equipment like video processors in cameras, TV's, STB's, media players etc.

Most of the time I have no luck disabling them, as they are usually hard coded somewhere in the firmware/driver.

But for Gamecube and now Wii games too, it's so nice to finally get rid of that veil that sits over everything and just subtly ruins everything.

If you can indulge me for a bit longer... I really don't understand why game devs use the filter for 480p output, because I can't see any benefit from it at all. It doesn't hide aliasing. It is NOT antialiasing. Pixel edges, stair-stepping, aliasing, is still plainly visible even with the filter on. For 480p it achieves precisely nothing.
 
Last edited by NoobletCheese,

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
In the interest of consistency I was thinking of making it like so:

Input fileOutput fileFurther user action required
Wii wbfs/isoPatched [GameID].dolCopy [GameID].dol to SD/USB and point USB Loader to it
GameCube isoPatched start.dolInsert patched start.dol into GameCube iso using GCR tool (GUI, doesn't require rewriting entire iso)
Wiiware wadA folder containing all files extracted from the wad, including the patched 00000001.app Pack folder to wad file using ShowMiiWads tool (GUI)*
* However it would only be one extra command line to automate this step, so I guess I may as well?
 
Last edited by NoobletCheese,

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
once the 00000001.app is modified, it has to be re-compressed again with wwcxtool

Are you absolutely sure about this?

i.e have you actually tried skipping the re-compression step and seeing what happens?

The reason I am curious is because...

Not every Wiiware game has a compressed 01.app

So maybe it doesn't have to be compressed back down again?

Maybe the developer just did it to save space?

The fact that you can choose which algorithm to compress with (even a different one than originally compressed with) is sort of consistent with the compression being invisible to the OS.

i.e the executable decompresses itself at run time, like compressed Windows executables.

I also noticed ShowMiiWads creates a smaller size wad after repacking than bfgr_wadpacker, and yet presumably they both produce a working game?
 
Last edited by NoobletCheese,

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
It seems there can be multiple versions of the same game with the same ID6, and thus I'd have no way to tell them apart, and so the patching offsets could be wrong for one of them.

eg. there are apparently 3 versions of NTSC Smash Bros Brawl (1.00, 1.01, 1.02) yet all have the same ID6 (RSBE01).

I've had a look through WIT commands and there doesn't seem to be anything that can extract this version metadata.

On the plus side, dol corruption needn't occur as the cloud data contains offsets AND the expected bytes at each offset, so if they don't match, then the USB Loader can simply decline to patch.

If anyone knows of a way to detect the game version, please let us know.

edit: just saw a newer version of WIT has a new command: ID8, which "Prints ID6 + 2 next bytes as disc and version number". Although I am not sure whether those next 2 bytes correspond to game version.

edit2: it's looking hopeful, as every game I have that is an original release is showing version 00.00, while Rev1's are showing 00.01 and Rev2's 00.02. I have PM'd the author for clarification.

The relevant command is eg:
Code:
wit ID8 --source "C:\Games\Super Smash Bros. Brawl (USA) (Rev 2)\Super Smash Bros. Brawl (USA) (Rev 2).wbfs"

Hopefully Wiiware wads don't have multiple versions.
 
Last edited by NoobletCheese,
  • Like
Reactions: Draxikor

Maeson

Well-Known Member
Member
Joined
Apr 3, 2013
Messages
1,180
Trophies
1
XP
3,387
Country
Spain
I have not tried to repack the wad with an uncompressed 01.app. But I do not know why would you want not to compress it again, specially if it's going to be installed on real nand.

Also I don't know what you mean with choosing algorithm, by using wwcxtool alone it compresses the app file automatically and the file always ends up with the same size it originally had.

I will check the size differences you mention with ShowMiiWads but I believe they are the same on my end.

Edit: You were right, the wad size made by ShowMiiWads is slightly smaller than a normal wad. But the content itself is the same (bar the changes made to 01.app), and when I install a game on Emunand, the actual content installed is the same for both wads.

Let's say, Art Style: Cubello's content has a real size of around 5.8mb when installing, and it's the same size when installling the unmodded wad and the rebuitl one. And of course every modded wad I did is working.

Lastly, I did not mention it, but I'm with you with the use of filters on 480p. It makes no sense to me, there's nothing to gain except if you are one of those people that think softer pictures look better than sharper ones (you know, trying to hide "pixels"), but to me you're only making things look blurry and worse. You can lower the sharpness on your TV while having an unfiltered picture and it will look much better than adding these filters...

I completely get filters on interlaced content, because having none is horribly harmful to your eyes, not to mention it raises the chances for epileptic attacks (specially playing on CRTs as far as I've read) but for progressive, that fixes everything wrong with interlaced pictures, just makes no sense. At all.

It's pretty great we have a way to make them disappear on Wii games now! With GC you could just force NTSC/PAL60 video modes to remove them (well, there's one game that did not seem to work with that, I think I'll try editing the dol for that one).

It'd be interesting to see if there's a way to remove it from the Wii Menu and Homebrew Channel, even if theyr'e far less important...
 
Last edited by Maeson,

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
I don't know what you mean with choosing algorithm, by using wwcxtool alone it compresses the app file automatically and the file always ends up with the same size it originally had.

I meant that you were using compression method 0x11:

to compress it back again after modified:
wwcxtool /c1 NameOfUncompressedfile.app 00000001.app

wwcxtool.txt said:
Usage
-----
wwcxtool [/u | /c0 | /c1 | /cr [ref] | /?] [/h, /p] [input] [output]
/u -- uncompress the input file
/c0 -- compress the input file using compression method 0x10
/c1 -- compress the input file using compression method 0x11
/cr -- compress the input file using the same compression method
of ref file if possible

If you are using /c1 for all games, you might have re-compressed some games using a different method than was originally compressed with.

If the game still runs regardless of compression method, then maybe it doesn't need re-compression at all.
 
Last edited by NoobletCheese,
  • Like
Reactions: Draxikor

Maeson

Well-Known Member
Member
Joined
Apr 3, 2013
Messages
1,180
Trophies
1
XP
3,387
Country
Spain
I completely overlooked that, sorry. Every 01.app I compressed back went to the exact same size of the original and it worked, so then it doesn't matter which one you use or miraculously all the games I edited used the same (which is not very likely as they were quite a few from different developers).

I also tried to made a wad without compressing the 01.app after modifying it, an don dolphin at least seems to work, I'll see on Emunand later. the game again is Art Style - Cubello because I had it already unpacked.
 

XFlak

Wiitired but still kicking
Member
Joined
Sep 12, 2009
Messages
13,810
Trophies
3
Age
38
Location
Cyprus, originally from Toronto
Website
modmii.github.io
XP
9,800
Country
Cyprus
In the interest of consistency I was thinking of making it like so:

Input fileOutput fileFurther user action required
Wii wbfs/isoPatched [GameID].dolCopy [GameID].dol to SD/USB and point USB Loader to it
GameCube isoPatched start.dolInsert patched start.dol into GameCube iso using GCR tool (GUI, doesn't require rewriting entire iso)
Wiiware wadA folder containing all files extracted from the wad, including the patched 00000001.app Pack folder to wad file using ShowMiiWads tool (GUI)*
* However it would only be one extra command line to automate this step, so I guess I may as well?

Just some thoughts on your plan, feel free to take it or leave it as you will.

When input file = Wii wbfs/iso, consider having an option so users can select what they want as the output: patched dol versus patched wbfs/iso (you can have the output file be in the same format as the input file, or maybe even better to force output files as wbfs since I think it's generally preferred, and I would even suggest forcing splitting it into 4GB chunks, or make this an option as well). You can add a warning to the option the impact it will have on run time and storage capacity. And if building an integrated options screen is something you don't want to spend time on, you can just have an xml or other config file that users can adjust to their liking.

When input is GameCube iso, I would suggest the same as above, but also based on your comment it sounds like using the GUI is quicker as it doesn't require rewriting the entire iso. If this cannot be easily optimized via cmd line to be as speedy, I would suggest automating mouse clicks to use the GUI when reconstructing the ISO (e.g. similar to how ModMii uses the official gui sneek installer, with an autoit script to automate mouse clicks and keyboard presses). Basically, if you want to script something and a good cmd line tool doesn't exist where a good gui does, consider just using the gui in your automation script by simulating mouse clicks and keyboard presses.

When input is a Wiiware wad, I would make the output a packed WAD (unless errors are detected). You can throw up some warnings as you mentioned previously if you are worried. But so long as users have Priiloader (or bootmii boot2) installed, they should be able to recover from this even if something goes wrong. So maybe recommend having these installed, or testing on emunand as you suggested earlier. Heck you could even direct people to ModMii (or wii.guide) for help installing Priiloader, Bootmii, etc.

On another note, all the work you're putting in is a bit ironic... because in a perfect world no one would even use your tool as usb-loaders will apply the same patches on the fly! Personally this is what I am waiting for. I couldn't be bothered to patch my games for Wiimmfi, but since I waited long enough now I don't have to, and I'm hoping the same thing happens here and eventually this gets integrated into GX and WiiFlow - fingers crossed! Either way, it wouldn't be possible without the effort you and MaeseJesus are clearly putting in to build a solid database, so thanks!
 
Last edited by XFlak,
  • Like
Reactions: eyeliner

Maeson

Well-Known Member
Member
Joined
Apr 3, 2013
Messages
1,180
Trophies
1
XP
3,387
Country
Spain
The problem is that I don't see loaders being capable of patching every single vfilter inside each main.dol for each game. They are in different spots for each one, and different games use different vfilters, maybe some games use vfilters that we don't even know yet, not to mention certain games have rogue vfilters sprinkled here and there without recognisable strings.

And to add to that, I just found a couple of games (Fishing Resort and Klonoa) with data that has the same hex values as one of the VFilters used for some Nintendo-made games "20 00 20 00 00 00 00", but as far as I can see they're not related to that, so we could run into modifying values just because they coincide and make games crash and such.

So unless someone dedicates MAJOR work for that feature, it's hard for me to see it happening.

I mean, right now loaders aren't even capable of forcing video modes to WiiWare titles, and only VERY few games can have their filters removed by forcing video options. In fact the only one I think I've seen is The Legend of Zelda: Twilight Princess, and it might only happen because it is a GameCube game at heart, and even then, only the NTSC version.

I would love to be proved wrong, though. It would solve many headaches for everybody.

Oh, and by the way, I tried messing around with that GC game I mentioned, R: Racing Evolution. Forcing video options on Nintendont did not work for this one, but editing Start.dol certainly did the trick. The vfilter data seems to be exactly the same for Wii games, at least for this one, and it had not one but two vfilters hidden. Quite surprised.

On the other hand, Metal Slug Anthology funny enough, being a 2D game does use vfilters unlike others (albeit that might be because it doesn't support 480p, and needs to be forced). The bad news is that the game is not well scaled so it has shimmering pixels, so the filters actually helped out masquerade that.

Maybe I could try different ones to see which would give us the clearest picture without showing the badly scaled picture... But for now I'll keep writing down more information for other games.

Here are a few more:

Code:
A Shadow's Tale    (American Title: Lost in Shadow) 
SDWP18    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    30CE32
                            3AAE9E
                            3ABEB6
                            3ABF6A
                            3ABFA6
                            3ABFE2
    04 08 0C 10 0C 08 04    3AAEDA
   
Boom Street (American Title: Fortune Street)
ST7P01    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    488892
                            48890A
                            488946
                            488982
                            4997BE
                            4AB418 > No string before it. 
    04 08 0C 10 08 04        4997FA

Endless Ocean 1
RFBP01    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    470882
                            470936
                            4709EA
                            470A9E
                            470B52
                            470C42
                            470CF6
                           
Endless Ocean 2
R4EP01    PAL
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    5F485E
                            5F95FA
                            5F96AE
                            5F9762
                            5F9816
                            5F98CA
                            5F99BA
                            5F9A6E
    04 08 0C 10 0C 08 04    5F489A
   
Excite Truck
REXP01    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    3044EA
                            304562
                            30459E
                            3045DA
   
Excitebots: Trick Racing 
RX3E01    NTSC            (NO PAL RELEASE)
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    4A2F4A
                            4A2F86
                            4A2FC2
                            4A2FFE
                            4A303A
                            4A3076
                            4A30B2
                            4B187E
    04 08 0C 10 0C 08 04    4B18BA
   
Fishing Resort 
SFVEXJ    NTSC             (NO PAL RELEASE) 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    54133A
                            541376
                            5413B2
                            5413EE
                            54142A
                            55634E
    04 08 0C 10 0C 08 04    55638A
                CAUTION:     On the Main.Dol file there is the string
                            "20 00 20 00 00 00 00". These exact same 
                            values can be find on some Nintendo-made 
                            games, and are VFilters. Here though, it 
                            seems to be other data. Do not modify!
                           
Klonoa: Door to Phantomile
R96PAF    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    43A4B6
                            43E812
                            43E88A
                            43E8C6
                            43E902
    04 08 0C 10 0C 08 04    43AF42
                CAUTION:     On the Main.Dol file there is the string
                            "20 00 20 00 00 00 00". These exact same 
                            values can be find on some Nintendo-made 
                            games, and are VFilters. Here though, it 
                            seems to be other data. Do not modify!
                           
Kororinpa: Ball-rolling Maze Game (American Title: Kororinpa: Marble Mania)
RCPP18    PAL 
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    2620D6
                            26218A
                            2621C6
                            262202
                           
Marbles! Balance Challenge (American Title: Marble Saga: Kororinpa)
RK6P18    PAL         This game is basically Kororinpa 2.
    VFilter:                Offsets
    08 08 0A 0C 0A 08 08    391652
                            41ECBE
                            41FCF6
                            41FDAA
                            41FDE6
                            41FE22
    04 08 0C 10 0C 08 04    41ECFA

I'll add more later.
 

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
On another note, all the work you're putting in is a bit ironic... because in a perfect world no one would even use your tool as usb-loaders will apply the same patches on the fly!

Indeed, the purpose of the tool is really just to discover the vfilters used by games so that we can build the database. Once we have the database, USB Loaders can do the patching and the tool won't be needed anymore.

The tool's ability to create a patched output file is sort of just a bonus feature in the interim. Previously I referred to it as a "one click solution", but in hindsight this is not correct — it's just a temporary tool as a means to an end, with a little bit of automation to save the user a bit of time from having to use hex editors and looking up gameID's etc.


When input file = Wii wbfs/iso, consider having an option so users can select what they want as the output: patched dol versus patched wbfs/iso

I was thoroughly debating myself about whether to include this feature. I estimate it would add an extra ~10mins to the patching time at USB 2.0 speeds, given WIT must extract the entire image (~3mins) then rebuild to iso (~3mins) and the user must copy it back to their USB drive (~3mins).

There is also potential risk of WIT not rebuilding it properly; there are some anecdotes of this happening with certain games in the WIT thread.

Given that ULGX has this unique feature of launching the patched .dol, it seems a shame to pass up the opportunity.


When input is GameCube iso, I would suggest the same as above, but also based on your comment it sounds like using the GUI is quicker as it doesn't require rewriting the entire iso. If this cannot be easily optimized via cmd line to be as speedy, I would suggest automating mouse clicks to use the GUI when reconstructing the ISO (e.g. similar to how ModMii uses the official gui sneek installer, with an autoit script to automate mouse clicks and keyboard presses).

I've just now seen GCR supports command line importing of files into the image. I missed it because the commands are only listed in GUI's help > about screen. I may as well automate it entirely then. This may be necessary anyway, since GCR mentions that to avoid rebuilding the entire image, the imported file must be exactly the same size, and the start.dol that WIT extracts is not the same size. However I had no issues importing WIT's start.dol despite it being different size. In HxD the only difference was some extra few bytes (mostly 00's) added to the end of WIT's.

edit: this explains it:
GCR readme said:
// You can try to import files a little bit bigger in size, than original ones.
// If GCR finds enough space between file you want to replace and a file,
// which follows it in image, you can do such import.

edit2: I also noticed that if I extract > import > extract with GCR, the file size is the same, but its checksum is not. In HxD the only difference is the second to last byte is changed to a different value.

When input is a Wiiware wad, I would make the output a packed WAD (unless errors are detected). You can throw up some warnings as you mentioned previously if you are worried.

I may as well do that, as it's only one extra command to pack it back to WAD.

However this comment worries me:

Wad files created by nusd are not compatible with bfgr_wadunpacker [command line tool for unpacking wads]. It is caused by either the bug of bfgr_wadunpacker or the bug of nusd (I knew why this happened, but didn't know which is right). For this wwpacker project, we won't do any modification to the original tools. Therefore, this compatibility issue won't be solved.

In that case I should probably ask the user if they want to repack it themselves or not.

edit: or perhaps I should use a different command line utility, such as WadMii or DolMii, which are part of Wii.cs Tools.
 
Last edited by NoobletCheese,

NoobletCheese

Well-Known Member
Member
Joined
Aug 12, 2018
Messages
533
Trophies
0
Age
25
XP
1,083
Country
United States
I'm not having any luck getting GCR to work at the command line, it just gives me this error:

Code:
System.NullReferenceException: Object reference not set to an instance of an object.
   at GCRebuilder.MainForm.Export(String expPath)
   at GCRebuilder.Program.Main(String[] args)

Seems to indicate GCR is not understanding the export path argument, but I've tried all kinds of path conventions and nothing works.

The correct command should be something like

Code:
gcr "C:\Starfox\game.iso" "&&SystemData\start.dol" "e" "C:\Starfox"

I've emailed the author.
 
Last edited by NoobletCheese,
  • Like
Reactions: eyeliner and XFlak

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    AncientBoi @ AncientBoi: Que dices?