Hacking VCFE Wip...

[lolsjoel]

I had no luck with your Icon Injector tonight. I tried three NES games injected into Kirby's Adventure, and after injecting the save icon, each game wouldn't play on the Wii, though each injection worked properly before. I had to go back and use HEXecute to inject the save icons and HEX edit the 01.app myself.

 

[HowardC]

I found the bug in the nes injection... I'll update once the other systems have been tested (to save effort in packaging in case there are more issues.)

 

[HowardC]

Well, it looks like nobody is willing to test this one for me.

Unfortuantely I don't have the time, but I'll release a new version that fixes the nes stuff tomorrow night.

 

[lolsjoel]

I'll try to give it a go on some different systems tomorrow.

 

[HowardC]

Found a bug in the u8tool caused by recent changes to it which fixed other bugs. I'll update it tomorrow. I'm also looking into the sound.bin issue. I think the reason some sound.bin's don't play when re-packed is that the 0.app header wants the uncompressed size of the file listed and official sound.bin files have lz77 compression applied to them. This would make sense to me as the uncompressed file we use as a working replacement doesn't use lz77 compression and some official sound.bin's play fine when re-packed.

Because of this, I've added preimenary extraction support for the sound.bin.... just for testing. Eventually I'll realease a stand-alone tool to deal with these like the cff tool. Don't get excited though, it merely removes the compression and saves the file based on it's format. So official sound.bins will extract a sound.bns file or a sound.aiff file, neither of which are readily playable on the pc. The unofficial one will extract to sound.wav though, which you can play on your pc!

 

[HowardC]

I'll try to give it a go on some different systems tomorrow.

I would appreciate that.

 

[HowardC]

I have good news to report.

I went ahead and tested my theories on why the official sound.bin doesn't work and I was correct. It turns out the header in the 0.app wants you to record the uncompressed file size, not the compressed one. I've already implemented this into the u8 tool, which will be released tonight.

Now more importantly, this might lead to fixing our issues with the brlyt file as well.

You see, the IMET (0.app) header asks for the file size of the sound.bin, banner.bin and icon.bin. Up until recently I've simply read the file length, recorded it, an left as-is. My experiments with the sound.bin lead me to believe this is wrong, however. You see sound.bin's recorded size, even if it isn't compressed, is NEVER the size of the file. If no compression is used, we record the size of the sound.bin minus 32 (the size of the IMD5 header) which gives us the size of the actual file and not all the header info. If it is compressed, we record the size of the file when uncompressed, which again ignores the first 32 bytes.

My point, the size is always at least 32 bytes smaller!

I THINK the wii is using these three values to allocate memory for the files when they are loaded (as in the case of lz77 files it could be larger than the actual file). A sound.bin with an incorrect file size has never been a big deal, because if it's too small then the file simply won't play, but it won't effect the other two files as it is the last to be loaded. Now banner.bin is a different story, it's the first to be loaded. Let's say we get the size too small.... normally this wouldn't be much of an issue.... there's a lot of empty space in a brlyt and chopping off a few bytes wouldn't hurt... BUT if the file is certain lengths, it'd start to effect the image files also included in the banner. If you try to load a tpl with a bit chopped off the end, you get the same kind of corruption we've been seeing.

Long story short, I'm gonna try to manipulate these values and see if it helps. If it does then I can simply use the same function I use for the sound.bin so it'll take mere minutes to implement.

*EDIT*

I went ahead and implemented this new size on the banner.bin and it appears to still load just fine. I haven't tested a long brlyt with it yet though. I'll do more testing tonight when I have time.

*EDIT2*

This also might be related to our issues with the icon.bin when we recompress it as well. I'm not saying gbalzss isn't also responsible, but it could be that it makes a lz77 of a different size when it re-compresses and that is what is causing the issue as again, a few bytes might get chopped off or added if the value is wrong.

 

[gundalf]

For C64 the banner.bin has to be LZ77 compressed or i get this strange corrupted channel.
And for the icon.bin i have removed the LZ77 compression (the sound.bin i have taken from an SNES WAD) and all works just fine.
For that i use Gally's tools, only for the banner.bin i use your u8tool.

I hope these informations may help you.

Oh and by the way i think that the first the Wii loads is the icon.bin, because that is the first you see in the Wii Menu.

 

[HowardC]

For C64 the banner.bin has to be LZ77 compressed or i get this strange corrupted channel.
And for the icon.bin i have removed the LZ77 compression (the sound.bin i have taken from an SNES WAD) and all works just fine.
For that i use Gally's tools, only for the banner.bin i use your u8tool.

I hope these informations may help you.

Oh and by the way i think that the first the Wii loads is the icon.bin, because that is the first you see in the Wii Menu.

It's just plain silly to mix and match mine and gally's tools as they both work exactly the same only mine allows the OPTION of lz77 compression. Only use mine from now on because there are bugs in his and due to file structure changes the two aren't completely compatable with each other. That isn't to say mine doesn't have bugs, but I'm still working on mine, so those bugs can actually be fixed.

The corruption has nothing to do with lz77 compression, it has to do with the length of the text fields you have edited. Sound.bin had worked fine with mine assuming it's a de-compressed one, which is available.

I hope that's helpful to you as you are doing things in a really round-about way.

 

[HowardC]

Well, no release tonight because I'm running into bugs, BUT I can pretty much confirm that our brlyt issues are related to these three values.

I tried smb with the three new values and an edited brlyt and I got a blank banner. So I thought "ok I'll try it with an unedited brlyt" and I got a corrupted banner, like what we get with the brlyt editor. The only way I could get it to display properly was to use the original sound.bin size calculation, which of course didn't let the sound.bin play.

I'll have to decompress a few official 0.apps and figure out what the values should really be. For the record gally's are incorrect as well, they are just a different incorrect.

 

[HowardC]

hmm... the plot thickens.....

I looked at the official 0.app for super mario bros. and confirmed that the values you are supposed to use when the file is compressed is the uncompressed value. The problem is when I use said values, I get a corrupted image. I'll have to investigate further, but we are on the right track!

 

[lolsjoel]

Well that's good to hear. Sorry I didn't get the chance to try the Icon Injector tonight. I've been too preoccupied with other things. It'll be a few days, now, before I can give it a shot.

 

[FGOD]

what if i have a 0.app that doesn't have a md5 hash? should i leave it blank or should i make a hash?

 

[lolsjoel]

If you're using Gally's tools, be sure to pack the banner.bin and icon.bin in the same session as you pack the 00.app. Otherwise the MD5 hash will not work.

 

[gundalf]

You see it, if you press on "Create Archive" (for gallys tool).

 

[FGOD]

yeah i know gundalf, but i still don't see it, but it might be cause i did it in 2 times

 

[FGOD]

no matter what i try i keep getting an empty hash on c64 packing with the 0.app from ik and with the custom c64 0.app are there other ways to extract the banner.bin and icon.bin from the 0.app from C64 wads? maybe the app from howard is causing the problem although it seems the only app that can extract them...

edit: it didn't even work when using the original internation karate wad file and the original ik 0.app from the ik wad not even from my custom duotris wad

 

[RadioShadow]

^ The Commodore 64 00.app should be the same as the rest. I'll have a look tomorrow myself and see what's going on.

You are just using HowardC's tool right?

 

[HowardC]

I can confirm personally that the c64 0.app works fine. I used it in my earlier brlyt tests because the wad is so small.

 

[FGOD]

I only used the tool from howard to unpack and pack the banner and icon, cause i was afraid it would result in a new banner brick cause with howard's tool it doesn't show the hash...