Hacking VCFE Wip...

[Noitora]

Nice tool, I just stumbled upon it

Keep up the good job HowardC

 

[HowardC]

Thanks for the tool radio shadow. Because it gives the addresses where it finds stuff it should be fairly easy to reverse engineer. Also the language detection is nice and assuming we can get it working on other emus, it might make sense to do it this way instead of through the brlyt editor.

The language thing doesn't work with the VC Wads. I've tried myself and it didn't work but feel free to try anyway.


Your tpl_edit_fe isn't dumping the images 100%:

Note: The red area is the transparent area. The tool dumped it as plain black.

Now it doesn't match the official logo that is used. Also to have a transparent affect, an 'alpha' colour needs to be set. This tells the Wii this colour is the transparent colour. Only works if set to 'RGB5A3'.

The alpha channel doesn't work, and it probably never will, tpl edit fe was never meant to replace the other tpl viewer, I just made it to be able to access the odd-ball tpls like neogeo and nes save tpls. Vb picture boxes don't support transparencies.

 

[lolsjoel]

Donno if the issue has been closed, but I just made a banner.brlyt with your tools and the first one (NES) was 9.73 KB and corrupt. Then I made the same brlyt with the size output set to 12288 and it worked brilliantly.

 

[RadioShadow]

Thanks for the tool radio shadow. Because it gives the addresses where it finds stuff it should be fairly easy to reverse engineer. Also the language detection is nice and assuming we can get it working on other emus, it might make sense to do it this way instead of through the brlyt editor.

The language thing doesn't work with the VC Wads. I've tried myself and it didn't work but feel free to try anyway.


Your tpl_edit_fe isn't dumping the images 100%:

Note: The red area is the transparent area. The tool dumped it as plain black.

Now it doesn't match the official logo that is used. Also to have a transparent affect, an 'alpha' colour needs to be set. This tells the Wii this colour is the transparent colour. Only works if set to 'RGB5A3'.

The alpha channel doesn't work, and it probably never will, tpl edit fe was never meant to replace the other tpl viewer, I just made it to be able to access the odd-ball tpls like neogeo and nes save tpls. Vb picture boxes don't support transparencies.

Then why have a tick box with the words 'Transparency'? >_

 

[stev418]

 

[HowardC]

RadioShadow: The transparency tick is more about the file format and less about actual transparent images.

loes: crap! Well, I'm not worrying about it right now, just save me a copy of the one that corrupted as well as the fixed one, maybe I can find a pattern.

stev: I haven't seen those used yet, but I am familair with the format. It's indeed lz77 compressed, it's just using the old gba/gamecube header. Obviously it can't read a compressed file header and thus why it crashes when you try to extract it. You added the wrong header man... put a "LZ77" at the front of that file.

 

[sr_corsario]

stev418 Yes, could be interesting to add the LZ77 option (look at mario rpg) and its probably easy to do.

To compress/decompress the rom are you using the correct tool? gbalzss?

See:

http://gbatemp.net/index.php?showtopic=95042&st=480

 

[stev418]

To compress/decompress the rom are you using the correct tool? gbalzss?

Yes, have tried gbalzss, doesnt seem to work out. When you say add LZ77, do you mean just LZ77 at start of hex? this didnt work, I also tried adding IMD5 + LZ77 to start of hex (used correct unheadered filesize and MD5)

I know how to make a IMD5 header, but maybe im not sure what makes up a LZ77 header

 

[sr_corsario]

To compress/decompress the rom are you using the correct tool? gbalzss?

Yes, have tried gbalzss, doesnt seem to work out. When you say add LZ77, do you mean just LZ77 at start of hex? this didnt work, I also tried adding IMD5 + LZ77 to start of hex (used correct unheadered filesize and MD5)

I know how to make a IMD5 header, but maybe im not sure what makes up a LZ77 header

With that gbalzss version works. You dont need to remove or add any header... just use the encode and decode option thats all. Then replace the old game file for the new one.


CODE

http://www.megaupload.com/?d=8GTLDV80

 

[HowardC]

Yeah, I was about to say, for the rom itself, you just need to use gbalzss. You do know that that rom isn't an actual archive right? There won't be anything readable about it.

Btw, I found a minor bug involving lz77 extraction on my u8tool. It would only effect these newer .arc files that are compressed though. I'm going to take a few minutes to add support for headerless compression.

If you want to post a link (or send me) the emanual.arc in question I can go over it to make sure there isn't any other crazy stuff going on.

**edit**

I wonder if this works on all files inside a 5.app archive? I've noticed on many vc wads that some things are just randomly compressed to save space. The files themselves don't have any headers (other than the filesize at the beginning) but they have LZ77 as the start of the file name. It makes me think this was done after the fact and that the wii filesystem itself automatically decompresses any files with such a filename.

 

[RadioShadow]

Donno if the issue has been closed, but I just made a banner.brlyt with your tools and the first one (NES) was 9.73 KB and corrupt. Then I made the same brlyt with the size output set to 12288 and it worked brilliantly.

Did you make sure the padding was set to '12000'?

To compress/decompress the rom are you using the correct tool? gbalzss?

Yes, have tried gbalzss, doesnt seem to work out. When you say add LZ77, do you mean just LZ77 at start of hex? this didnt work, I also tried adding IMD5 + LZ77 to start of hex (used correct unheadered filesize and MD5)

I know how to make a IMD5 header, but maybe im not sure what makes up a LZ77 header

With that gbalzss version works. You dont need to remove or add any header... just use the encode and decode option thats all. Then replace the old game file for the new one.


CODE

http://www.megaupload.com/?d=8GTLDV80

*tries that*

EDIT: Well compressing Panel De Pon and inserting it into Secret of Mana doesn't work.

 

[HowardC]

You might to elaborate a little more on what you did, but at least for extraction, it works just fine (that is the same version of gbalzss we normally use btw). I just noticed that splatterhouse for the tg16 is compressed so i ran it through gbalzss and then fired up the rom on the magic engine and it ran just fine. I even re-compressed it with gbalzss and the resulting file was the same size as the one in the wad.

I've added support for archives with headerless compression to my u8tool, but I don't have any of these compressed archives on hand so I have no way of testing it. If anybody has one send it my way and I'll release the thing as soon as we know it's working.

 

[stev418]

HowardC, Ive pm'd you a sample of the LZ77emanual.arc

Also just to clarify, LZ77JCTJ.rom, LZ77emanual.arc are both of the same headerless format, so gbalzss doesn't decompress either.

 

[HowardC]

hmm.... there's something wrong with this file alright. Have you installed this wad and confirmed it to work?

Here's the deal, those few bytes before the start of the u8 header are supposed to be the size of the file once it's decompressed. The problem is this value is wrong. The value given is actually a few thousand bytes LESS than the size of the current file, which is impossible. Unfortunately gbalzss (and pretty much any other decompessor) needs the correct output size to properly decompress the file.

**edit**

I take that back.... normally even if the header is a bit screwed up gbalzss will figure it out. This is obviously using some form of lz77 compression or it wouldn't be named like that, but the normal decompressors aren't working.

 

[stev418]

hmm.... there's something wrong with this file alright. Have you installed this wad and confirmed it to work?

Here's the deal, those few bytes before the start of the u8 header are supposed to be the size of the file once it's decompressed. The problem is this value is wrong. The value given is actually a few thousand bytes LESS than the size of the current file, which is impossible. Unfortunately gbalzss (and pretty much any other decompessor) needs the correct output size to properly decompress the file.

**edit**

I take that back.... normally even if the header is a bit screwed up gbalzss will figure it out. This is obviously using some form of lz77 compression or it wouldn't be named like that, but the normal decompressors aren't working.

Have tested wad on my PAL system (set to ntsc video with any region changer) it is working, I even had a browse though the emanual

so looks like a derivative of ? LZ77 :\

 

[lolsjoel]

Donno if the issue has been closed, but I just made a banner.brlyt with your tools and the first one (NES) was 9.73 KB and corrupt. Then I made the same brlyt with the size output set to 12288 and it worked brilliantly.

Did you make sure the padding was set to '12000'?

Oh, sorry. I think the first time the padding was set to +64. Not sure why I chose to do that, though. Sort of a stupid thing to do.

 

[HowardC]

hmm.... there's something wrong with this file alright. Have you installed this wad and confirmed it to work?

Here's the deal, those few bytes before the start of the u8 header are supposed to be the size of the file once it's decompressed. The problem is this value is wrong. The value given is actually a few thousand bytes LESS than the size of the current file, which is impossible. Unfortunately gbalzss (and pretty much any other decompessor) needs the correct output size to properly decompress the file.

**edit**

I take that back.... normally even if the header is a bit screwed up gbalzss will figure it out. This is obviously using some form of lz77 compression or it wouldn't be named like that, but the normal decompressors aren't working.

Have tested wad on my PAL system (set to ntsc video with any region changer) it is working, I even had a browse though the emanual

so looks like a derivative of ? LZ77 :\

Well there's actually a few variants of lz77, the problem is it's hard to find tools for them. There's lz778, lzss (which is essentially the same as lz77) and a few others. Wasn't there a special tool we found that worked for unpacking and repacking a save icon on the c64? I'll bet it'd work as it was one of those "LZ77Filename.ext" files. The strange/annoying thing is the "LZ77N43401LL.BIN" in slaughterhouse decompressed just fine, which means there are multiple formats of these new "LZ77" files. I have no clue how to tell one from the other even if we find a tool that works.

 

[HowardC]

well, i ran the file through gbadecmp and none of it's decompression routines did the trick. It's interesting to note though that it didn't crash when I ran it, which it'd normally do if I fed it an invalid file.

If anyone has any ideas I'm all ears.

 

[Blue-K]

Would it be possible to create Banners with this, and then Inject instead a ROM an Emulator-File (.dol .elf), so that an Emulator will start?

Oh, and I get this message always:

Component comdlg32.ocx is not registered or something like that...Ideas?

 

[HowardC]

Would it be possible to create Banners with this, and then Inject instead a ROM an Emulator-File (.dol .elf), so that an Emulator will start?

Oh, and I get this message always:

Component comdlg32.ocx is not registered or something like that...Ideas?

Yes, but because you've had to ask this question I'd suggest you don't. Atm my tools are beta and you have to know what you are doing to use them. The people responding in this thread are pretty much my beta testers.

comdlg32.ocx is probably missing from the archive. It's included with many of my tools. Simply copy it from the folder of a tool that does use it to the one that is causing your problems.