Hacking VCFE Wip...

[HowardC]

Both banner.brlyt files were 12KB. Download them here.

No they aren't.

Mario rpg is 11,924 bytes and Piccross is 11,656 bytes. I'm guessing you are checking filesize by simply reading it from windows explorer. That is incredibly inaccurate as it rounds to the nearest kb. You need to right click on the file and view its properties to get the actual byte size.

 

[RadioShadow]

That's what is the problem!! The god damn size!

I added 268 (dec) of '00' hex values into Mario Picross 'banner.brtyl' file and it fixed the problem! I can't believe that was the bloody problem all this time!


Basically, we need to make sure the file is bigger than 11,924 bytes (or 12KB exact)!

*goes and fixes ALESTE to confirm this*


EDIT: It worked! I made the ALESTE 'banner.brlyt' file from '5525KB' to '12000KB' and it fixed the problem.

 

[HowardC]

Well that definately helps to determine the problem, but we need to go further than that. I think it might be another "multiple of" deal.

Just from the ones I've been looking at, all the corrupted files aren't divisible by 8, and all the ones that work are.

I won't have access to my wii for quite a while, but if you want you can try just adding a few nulls to the end of the file (to make it a multiple of 8) and see if that works. I can easily pad the files to any length to ensure they work, but we want to get the padding as small as possible. Also making the file 12kb isn't practical if the title is REALLY long or REALLY short.

I found some other interesting differences between the two files though. The bfrna material header differs between the two files. The odd thing about that is, it should ALWAYS be the same. The bfrna header basically tells the group name offsets at the bottom. There isn't a value that tells where the group offsets start, its just relative offsets... thus it should always be the same on the consoles. The mario rpg brlyt is nice and ordered, with all 5 groups having the same size. The piccross banner has a cascading header, with each group gaining approx 16 bytes, which is insaine. My guess off the top of my head is that maybe the header is getting screwed up when gbalzss decompresses it? It doesn't really matter though as the header doesn't seem to actually do anything important. You can screw with that thing all you want and it doesn't change the banner afaik.

Long story short, adding 4 bytes or so to the end of the file should fix it, so try that as well.

So it is a packing issue AND a brlyt issue (sort of).

We also need to find a banner with an uber-long brlyt so we can find a compatable brlyt that is OVER 12kb, to confirm.

A really short one that works would be nice as well, but I'm pretty sure all we need to so is add a bit of a buffer at the end of the file.... not a crazy big length, just 4-16 bytes.

We are on the right track guys, keep it up!


p.s. If you guys REALLY want unicode support so bady I can add it with forms 2.0 quite easily (always could have). The thing is, I'm not going to illegally distribute the forms2.0 dll, so we need to figure out an alternative. I could put a html file in with the apps that points to the download from m$ (which is perfectly legal, oddly enough) but m$ changes their urls all the time, so it might be confusing. Of course if you have any version of office, you don't have to even bother. Let me know what you think on that one.

EDIT:

actually it's NOT a multiple of 8 we are after.... it's a multiple of 12! That is wierd as hell as all hex files generally use bases of 4, or 8

 

[lolsjoel]

Well, I'm happy to say I just made my first inject with 100% HC tools. I've done plenty of other using a few of them, but this was 100% Gally/HEX free. I made a Genesis game using CCF Tool 2.0, U8Tool 7.1, Brlyt Tool 7.1, VC Icon Generator 8.0. Admittedly, I did not use the save injector since the icon generator doesn't output files with the correct name, I figured I needed to go handle them once, I might as well just move them myself. That said, using your tools, everything went perfectly, namely the icon.bin, banner.brlyt and sound.bin all worked flawlessly. Unfortunately, the game didn't

. I injected Revolution X, and found that once an actual game is started, the game plays, but without any graphics. Bummer.

After having such good luck with the Brlyt Tool, I went ahead and tried to finish up a game I'd started long ago - Teenage Mutant Ninja Turtles^Hyperstone Heist. Unfortunately, though, the brlyt did corrupt. Could that possibly be because I packed with Gally's tools?

EDIT: Just had a second go at TMNT, and found that when I unpacked and repacked with HC's U8 Tool (and having made a new banner.brlyt), the banner doesn't get corrupt! Course, there was another change made, and that was that the old banner was for 1 player, this one is for 2, though I don't see how that could have made any difference. Well, I've got to tip my hat to you, Mr. C. Excellent tools.

 

[HowardC]

Actually the Icon generator's output names are irrelevant due to the way I copy the files with the injector. Instead of copying the file over, I copy it into the first "banner_____.tpl" it finds. So it should always copy the file correctly. Same deal with wte files. (at least the main one).

Regarding tmnt.... yes, changing the number of players from 1 to 2 DOES make a size difference. Remember, you changed it from 1 to 1-2, which adds bytes.

 

[lolsjoel]

Well, that being said, I had previously made the same brlyt with 2 players using your old brlyt maker and Gally's tools to pack, but that left the banner corrupted in the past. But it's working now, so all is well.

Moving on, though, I tried my had at an old Master System inject again, and wasn't able to get it working right. Has it been brought up before that using your Icon Generator on a SMS WAD leaves the IconVCPic.tpl corrupted? It displays the image, but distorted, much like a corrupted brlyt would do. I guess I've made the IconVCPic with Gally's tools and had the same problem, too, though. I've packed with your new U8 Tool and Gally's U8 Packer, and both leave me with a messed up banner. Thoughts on that?

 

[HowardC]

Just that sega games are wierd, so it could be the icon.tpl is in a different format and that the icon.bin has a brlyt as well.

 

[stev418]

just popped in to say thanks for the great set of tools, just wondering if anyone has a theory to my latest problem though.

I can no longer pack a 'working' wad on my PC, I needed to copy my bfgr_wadtools_v039a folder to my other PC to unpack/pack the wad. This has got me really stumped, as it appears something on my first PC in getting between the unpack and pack procedure.

EDIT: I just had a quick look and on my NON-working PC, the extracted .trailer file is always 1kb larger then the 00.app :\, whereas the working PC extracts them at the CORRECT same size.

EDIT2: I have found that i need to UNPACK on 2nd PC, I can PACK fine on my first PC, very weird. So for some reason the UNPACKING is not working on first pc

 

[HowardC]

maybe you don't have a common key ?

Guys I just wanted to give you a heads up that I found another minor bug in the u8tool, which could be causing our issues. It appears that u8 archives with an imet header force an extra blank line in-between each file even though there aren't any folders. Now this shouldn't have caused any of our issues, but you never know.

I have updated the tool to account for this, but it isn't ready for a release yet as I threw in unicode support via forms 2.0 just to see how practical it would be to use.

 

[stev418]

maybe you don't have a common key ?

Na, lol . Ive been packing wads and making customs for a long while, thats why its got me stumped. One PC just wont unpack correctly anymore, it packs fine - and I have used the EXACT same common-key.bin on both pc's

 

[RadioShadow]

Well that definately helps to determine the problem, but we need to go further than that. I think it might be another "multiple of" deal.

Just from the ones I've been looking at, all the corrupted files aren't divisible by 8, and all the ones that work are.

I won't have access to my wii for quite a while, but if you want you can try just adding a few nulls to the end of the file (to make it a multiple of 8) and see if that works. I can easily pad the files to any length to ensure they work, but we want to get the padding as small as possible. Also making the file 12kb isn't practical if the title is REALLY long or REALLY short.

I found some other interesting differences between the two files though. The bfrna material header differs between the two files. The odd thing about that is, it should ALWAYS be the same. The bfrna header basically tells the group name offsets at the bottom. There isn't a value that tells where the group offsets start, its just relative offsets... thus it should always be the same on the consoles. The mario rpg brlyt is nice and ordered, with all 5 groups having the same size. The piccross banner has a cascading header, with each group gaining approx 16 bytes, which is insaine. My guess off the top of my head is that maybe the header is getting screwed up when gbalzss decompresses it? It doesn't really matter though as the header doesn't seem to actually do anything important. You can screw with that thing all you want and it doesn't change the banner afaik.

Long story short, adding 4 bytes or so to the end of the file should fix it, so try that as well.

So it is a packing issue AND a brlyt issue (sort of).

We also need to find a banner with an uber-long brlyt so we can find a compatable brlyt that is OVER 12kb, to confirm.

A really short one that works would be nice as well, but I'm pretty sure all we need to so is add a bit of a buffer at the end of the file.... not a crazy big length, just 4-16 bytes.

We are on the right track guys, keep it up!


p.s. If you guys REALLY want unicode support so bady I can add it with forms 2.0 quite easily (always could have). The thing is, I'm not going to illegally distribute the forms2.0 dll, so we need to figure out an alternative. I could put a html file in with the apps that points to the download from m$ (which is perfectly legal, oddly enough) but m$ changes their urls all the time, so it might be confusing. Of course if you have any version of office, you don't have to even bother. Let me know what you think on that one.

EDIT:

actually it's NOT a multiple of 8 we are after.... it's a multiple of 12! That is wierd as hell as all hex files generally use bases of 4, or 8

The file might be able to be bigger, the estimate sizes I've seen for banner.bytyl files are 6KB, 10KB and 12KB.

How long can the titles be in the banner.bin files (40 letters per line is I remember correctly)? What do you mean by a multiple of 12?


The unicode support is a good idea. You will just have to mention about obtaining the file if necessary.



QUOTE(loesjoel @ Oct 22 2008, 03:22 AM) Well, that being said, I had previously made the same brlyt with 2 players using your old brlyt maker and Gally's tools to pack, but that left the banner corrupted in the past. But it's working now, so all is well.

Moving on, though, I tried my had at an old Master System inject again, and wasn't able to get it working right. Has it been brought up before that using your Icon Generator on a SMS WAD leaves the IconVCPic.tpl corrupted? It displays the image, but distorted, much like a corrupted brlyt would do. I guess I've made the IconVCPic with Gally's tools and had the same problem, too, though. I've packed with your new U8 Tool and Gally's U8 Packer, and both leave me with a messed up banner. Thoughts on that?

Did you compress the icon.bin? Compressing it with LZ77 causes the picture to not display right. Just unpack it again with HC's U8 tool and repack it without the LZ77 compression.

 

[dritz]

Not sure if this will help but it seems to be something with the U8tool.
Because I unpacked and packed king of fighters 94 00000000.app. Then repacked it with no changes and the banner was corrupt.
I then went back and did the same thing with the 5.0 version of the tool and there was no corruption. I then proceeded to change the files with multiple different name lengths and years. Also changed from 1 and 2 players. Every file worked with no corruption. I even used compression with the banner.bin.
All changes were also done with the brlyt editor.
I can upload the 00000000.app files, the original,7.1 version and 5.0 version tommorrow if you want to see them.

 

[HowardC]

Not sure if this will help but it seems to be something with the U8tool.
Because I unpacked and packed king of fighters 94 00000000.app. Then repacked it with no changes and the banner was corrupt.
I then went back and did the same thing with the 5.0 version of the tool and there was no corruption. I then proceeded to change the files with multiple different name lengths and years. Also changed from 1 and 2 players. Every file worked with no corruption. I even used compression with the banner.bin.
All changes were also done with the brlyt editor.
I can upload the 00000000.app files, the original,7.1 version and 5.0 version tommorrow if you want to see them.

This is a known issue and has been around since the beginning of vc hacking. Neogeo banners, without modification, corrupt when you re-pack them. The fact that it worked in 5.0 is just a fluke and shows how badly 5.0 was screwed up. The padding issue radioshadow and I are discussing will evenually fix this (I hope!). The files wouldn't help me as I don't intend to play "wack a mole" getting every banner to work. If I fixed neogeo then it'd probably break one of the other consoles. Also you don't mention changing any of the images. Before the neogeo corrupted once you swapped out some images.

 

[HowardC]

The file might be able to be bigger, the estimate sizes I've seen for banner.bytyl files are 6KB, 10KB and 12KB.

How long can the titles be in the banner.bin files (40 letters per line is I remember correctly)? What do you mean by a multiple of 12?


The unicode support is a good idea. You will just have to mention about obtaining the file if necessary.

I honestly don't remember the maximum length, but I'm not sure if it'd help us. With so many variations of the brlyt structure even if we knew how big all the texts would be we would never know if extra stuff (esrb, 60hz warning) were added making it even bigger. It might give us a rough idea though.

By multiple of 12 I mean the entire file must be divisible by 12, or more accurately (now that I've looked more) It has to divide by 8 and have a remainder of 0.5 or greater. 0.5 would make it a multple of 12, but .75 works as well. Fixing the issue might be as simple as adding 16-32 bytes at the end for good measure though.

In more visual terms, all banner.brlyt files end with "gre1...." Of course when you pack up everything into banner.bin, all the ends of the files are padded to make it an even line of 16. Depending upon the file length, sometimes "gre1...." is all on the same line and that is padded. Those banners seem to work. When that whole last phrase isn't on the same line, it seems to break. At least that's what it appears to be.

The u8 structure continues to confuse me in it's seeming lack of standardization. I thought I needed to update the u8tool because some 0.apps I ran across has a blank buffer line between each file. Now I look at some of the earlier brlyts and they do NOT have the lines. So it leaves me scratching my head.... are these files both correct? If so why does one have buffer lines and another not and more importantly will omitting these lines corrupt a banner? Will adding these lines to a console that normally does not have these lines corrupt a banner?


Btw I added unicode support to the u8tool just to test how difficult it'd be. I had to write two custom functions (as vb's unicode converters screw mixed text up) but it actually ends up being simplier than the function I currently use to strip english text down to asc and I don't have to determine if the text is unicode or asc. So I'll probably go back and add it to my other apps if only for the reason that it cleans up my code.

 

[HowardC]

I went ahead and added unicode support to the brlyt editor last night, just to test. The changes seemed to go pretty smoothly, but I'll need to test a few more times to make sure it is outputting the correct files.

While we are on the subject, is there anyone available that can read Japanese? You know how I turncate the year and player entries to make them simplier and fill in the "Released: " and "Players " after the fact? Well once I got the japanese text working, it became apparent that I can't easily tell what I'm supposed to crop off (and put back later) for the players entry for a Japanese file.

A typical year entry looks like this: (Taken from Aleste)

１９８８年発売

As you can see, that one is fairly obvious, the exception being the 1988 is on the left, as asians read from right to left.

Now the player entry entry looks like this:

プレイ人数
1人

Yes, there is actually a second line! As you can see, there is indeed a "1" in there, but it's followed by another character and sadly I don't have any two player japanese games to compare it to.

So if anyone can help, I'd appreciate it, otherwise the text would have to be manually edited for these games via the hardcore text function.

**EDIT**

Actually I DO have a two-player Japanese banner so I can probably muddle through it, but I'd still like to know out of curiosity.

As halloween is getting closer and closer, I have less and less time to work on this stuff, so while I will keep responding to questions, ect... don't expect any releases until november.

 

[RadioShadow]

A typical year entry looks like this: (Taken from Aleste)

???????

As you can see, that one is fairly obvious, the exception being the 1988 is on the left, as asians read from right to left.

Now the player entry entry looks like this:

?????
1?

Yes, there is actually a second line! As you can see, there is indeed a "1" in there, but it's followed by another character and sadly I don't have any two player japanese games to compare it to.

So if anyone can help, I'd appreciate it, otherwise the text would have to be manually edited for these games via the hardcore text function.

**EDIT**

Actually I DO have a two-player Japanese banner so I can probably muddle through it, but I'd still like to know out of curiosity.

At least you didn't update. I might not be much help for a while.

There is a youtube video showing a two player Japanese banner. It goes like:

?????
1?2?

See end of Youtube video.

 

[HowardC]

That sucks man! What did the update do to your wii?

If the wii is no longer accepting trucha-signed wads after the update, it might be a good idea for us to build a signer right quick. There are already apps out there that can get your wii's keys, it'd just be an extra step.

 

[RadioShadow]

It fixed all the bugs in the ISO's so WADs can't be installed and not all the programs work in Homebrew. There is a solution to fix the problem for those who haven't updated but for those who have updated are screwed ATM.

Also just on my Wii, it won't load the Wii Shop Channel but on my brothers Wii, the Wii Channel loads fine. Not sure how I'm going to get that fixed.

But a app that can pack them with the user's Wii common-key would be helpful.

EDIT: How do you obtain the common-key.bin from my Wii (if I can)?

 

[HowardC]

I wish I had a link for you, but honestly I forgot the name. It's a team tweezer app I think and basically it dumps your keys to the sd card. You'll have to look for it. I do remember that the name of the app doesn't give you ANY clue as to what it does, so that makes things difficult.

 

[Mrkinator]

just popped in to say thanks for the great set of tools, just wondering if anyone has a theory to my latest problem though.

I can no longer pack a 'working' wad on my PC, I needed to copy my bfgr_wadtools_v039a folder to my other PC to unpack/pack the wad. This has got me really stumped, as it appears something on my first PC in getting between the unpack and pack procedure.

EDIT: I just had a quick look and on my NON-working PC, the extracted .trailer file is always 1kb larger then the 00.app :\, whereas the working PC extracts them at the CORRECT same size.

EDIT2: I have found that i need to UNPACK on 2nd PC, I can PACK fine on my first PC, very weird. So for some reason the UNPACKING is not working on first pc

I had this problem too. It wouldn't unpack properly but would pack just fine. I tried unpacking at a friends house and it worked fine.

So I guess It just certain computers

, hopefully there will be a fix soon.