Hacking VCFE Wip...

[RadioShadow]

For the very reason that certain numerals don't display properly, all the apps (except the u8 tool, where it isn't as important) have been modified to use the wii font. If you have the wii font (found in any 4.app) installed on your system it should look fine, but the font will be blurry and look bold (even though it's not). Because different windows fonts display unicode so differently this seemed to be the best solution as it's the actual font your wii will use. I would include the font or add a link to it, but it's property of nintendo. I know I'm being a real pain in the butt about stuff like that, but I'm trying to keep my tools legal and except for the logos I included with the brlyt editor (which we should be able to legally use as they are promotional logos) we aren't using any nintendo code or nintendo files and thus nintendo could NEVER force me to remove them.

If using Nintendo's Font is bad, why can't your tools just use the font that the U8 uses? Or is that font set up differently to the Wii's font?

 

[lolsjoel]

Gotta report that two tools didn't work properly for me just now.

The newest brlyt editor corruped with a NES banner.brlyt named Klax / 1990 / 1 and +64 padding.
Also the newest icon injector half failed, in that the banner injected fine, but the text didn't show on the system.

 

[vettacossx]

This is most impressive indeed! thanks you guys cant wait to see this all merged into one tight application with a hot gui (easily one of the best contributions to the scene!)

 

[HowardC]

Well RadioShadow, because IMO the u8tool's font is fairly unreadable as well, but just barely readable to make due for the u8tool, which doesn't have much text to edit. The wii font is a much better representation of how it is going to look. Honestly the font I use on the u8tool looks like crud on my system... not at all like in your screenshots.


loesjoel:

Some have already reported that adding +64 bytes wasn't fixing the banner so what made you think it'd work different for you? I guess I'm talking to myself when I write the readme as it points out that +64 bytes is just a random number I used and that we don't know the optimum number yet.

I'll look into the save injection, but you haven't told me what game/system/ect so I can't do anything until you tell me what went wrong.


Just in general I'd like to say that I REALLY appreciate the help finding bugs, but it would help me more if you guys would investigate a little yourselves as to what is going wrong when you report back "this isn't working". Get a hex comparator, compare the unedited file with the edited one, and post any differences.

 

[lolsjoel]

loesjoel:

Some have already reported that adding +64 bytes wasn't fixing the banner so what made you think it'd work different for you? I guess I'm talking to myself when I write the readme as it points out that +64 bytes is just a random number I used and that we don't know the optimum number yet.

I'll look into the save injection, but you haven't told me what game/system/ect so I can't do anything until you tell me what went wrong.

I did read the readme, and saw that you said 64 was a guess and you were just going to see if that would make it work, that you were trying to minimize the number of buffer added. So forgive me for reporting back that it didn't work out for me. The size of the brlyt was 12822 bytes, but the size on disc was around 9400 bytes. I tried another game, but changed the buffer to 128, and that banner didn't corrupt, but it was just another random number and a different game all together (though also NES).

The save injector, sorry, was for the same game. So it was Klax on the NES.

 

[HowardC]

Nes bug found and squashed. See that's how quick it happens.

I'll post an update in the morning. I suspect we'll run into more of these as the unicode support changed a lot of code.

I'm not sure why you are getting upset at me, I'm the one getting reports of "it didn't work" without any explaination. I mean it could be just me, but it sounds like you guys a trying one game once with the default settings and if it doesn't work immediately you run to your computer and post that it's not working. Figuring out this buffer number is going to taking some "playing around".

Remember, if we can't figure out a nice small number, we do know that 12kb works so we can always just use that.

 

[HowardC]

Ok guys, I've got bad news......

I thought since I FINALLY have some free time I'd try to figure out the optimum padding size myself and I've yet to get this one banner to uncorrupt!

I took a stock super mario bros wad and changed the title to "Super Mario Bros. 12345678" and no amount of padding seems to fix it.

RadioShadow: Can you tell me the EXACT byte size you've been adding to get these to fix and any misc details you might be leaving out?

I went back and read your post and it didn't make a lot of sense to me because you mention 12kb a lot and yet none of the values you mention changing them to are 12kb (which is 12288 bytes btw, 1024 x 12). I tried a few of them but no luck. Any help would be appreciated because if it isn't something I'm doing wrong (ie the wrong value) then we are back to square one as your solution isn't a universal one.

UGH I thought we had this issue behind us.

 

[marioxb]

Ok guys, I've got bad news......

I thought since I FINALLY have some free time I'd try to figure out the optimum padding size myself and I've yet to get this one banner to uncorrupt!

I took a stock super mario bros wad and changed the title to "Super Mario Bros. 12345678" and no amount of padding seems to fix it.

RadioShadow: Can you tell me the EXACT byte size you've been adding to get these to fix and any misc details you might be leaving out?

I went back and read your post and it didn't make a lot of sense to me because you mention 12kb a lot and yet none of the values you mention changing them to are 12kb (which is 12288 bytes btw, 1024 x 12). I tried a few of them but no luck. Any help would be appreciated because if it isn't something I'm doing wrong (ie the wrong value) then we are back to square one as your solution isn't a universal one.

UGH I thought we had this issue behind us.

This is how I've been getting them to work. I pad the file to exactly either hex address 24D5 or 339D (not sure what those translate to in bytes), whichever is smaller, but over the edited file size. Doing that seems to get it to work properly, no matter what. For example, I changed the SNES Zelda into Teenage Mutant Ninja Turtles IV^Turtles in Time with the previous brlyt editor and padded the file to hex address 339D and it worked great.

Oh yeah, and I just happened to come across those numbers by a happy accident. I just copied and pasted 00 until I got something that worked. Now everytime I have a banner that doesn't display properly, I just copy and paste the 00's from one of my working files, then add or delete them until I get to one of those "magic numbers".

Is there a way to have your program to know what the file size is after all edits have been made, and then automatically pad to either hex address 24D5 or 339D? Or maybe it can pad to an address higher than both and it could then trim what's unnecessary?

 

[RadioShadow]

RadioShadow: Can you tell me the EXACT byte size you've been adding to get these to fix and any misc details you might be leaving out?

I went back and read your post and it didn't make a lot of sense to me because you mention 12kb a lot and yet none of the values you mention changing them to are 12kb (which is 12288 bytes btw, 1024 x 12). I tried a few of them but no luck. Any help would be appreciated because if it isn't something I'm doing wrong (ie the wrong value) then we are back to square one as your solution isn't a universal one.

UGH I thought we had this issue behind us.

If I had the file, I would happily tell you the exact size. I can easily find out again know. From memory it was '12000KB'.

However, my first test on using the brtly tool, the image was fine. Although I'm going to be creating two custom SNES WADs tomorrow so I'll see what happens.

The UNICODE function seems to be working as well. My Bare Knuckle III dump is fixed (doesn't say 'Streets of Rage 3' when I highlight icon channel).

 

[marioxb]

My Bare Knuckle III dump is fixed (doesn't say 'Streets of Rage 3' when I highlight icon channel).

When I purchased Bare Knuckle 3, and switched to US mode on the Wii, without dumping anything yet, it said "Streets of Rage 3". It's kinda funny that certain parts of the banner change based on the region setting of the Wii, but other things, such as the text "inside" of the banner, the manual, and the game itself, don't change languages (well between Japan and US, at least). The NeoGeo is the only exception to the rule, where the region of the game changes with the region of the Wii. (Not the manual or the banner, however).

 

[Xta Large]

When I try to use this program it says I'm missing a whole load of assets. FM20.dll is my current issue, can anyone help me? I've tried to use cmd to register the dll but that's not working.

 

[Xta Large]

Nevermind, I got Forms 2.01 and everything EXCEPT for the Save Icon Injector work now.

 

[marioxb]

Nevermind, I got Forms 2.01 and everything EXCEPT for the Save Icon Injector work now.

Yeah, there ya go. So I'm not the only one! I have the same problem. I installed ActiveX Control Pad and it made everything but the save injector work for me.

 

[HowardC]

RadioShadow: Can you tell me the EXACT byte size you've been adding to get these to fix and any misc details you might be leaving out?

I went back and read your post and it didn't make a lot of sense to me because you mention 12kb a lot and yet none of the values you mention changing them to are 12kb (which is 12288 bytes btw, 1024 x 12). I tried a few of them but no luck. Any help would be appreciated because if it isn't something I'm doing wrong (ie the wrong value) then we are back to square one as your solution isn't a universal one.

UGH I thought we had this issue behind us.

If I had the file, I would happily tell you the exact size. I can easily find out again know. From memory it was '12000KB'.

However, my first test on using the brtly tool, the image was fine. Although I'm going to be creating two custom SNES WADs tomorrow so I'll see what happens.

The UNICODE function seems to be working as well. My Bare Knuckle III dump is fixed (doesn't say 'Streets of Rage 3' when I highlight icon channel).

12000kb is 12 megs, which would be insaine. That's why I asked.

Mario, based on what you are saying then this solution is another dead-end. If the file size needs to be different for each game then there's no way I can have vcfe automatically pad the file to the right length.

Btw I think what you described is already setup in the padding function (as explained in the readme). If you put a "+" symbol in front of the byte size in the pad box it means "add this many bytes", but if you OMIT the "+" then it means "pad until the filesize equals this many bytes".

I'm not sure what is causing the issue with the save injector. Can you two post some general system specs? (Os, service pack, ect...) I've been told that forms 2.0 pretty much won't work on a windows 2000 pc, giving random automation errors but that's all I can think of.

 

[marioxb]

Mario, based on what you are saying then this solution is another dead-end. If the file size needs to be different for each game then there's no way I can have vcfe automatically pad the file to the right length.

Actually, I think that the higher number will work regardless. I tried the lower one first, and it only works if the file is not already past that point already. Give me a few days to test this theory.

 

[RadioShadow]

RadioShadow: Can you tell me the EXACT byte size you've been adding to get these to fix and any misc details you might be leaving out?

I went back and read your post and it didn't make a lot of sense to me because you mention 12kb a lot and yet none of the values you mention changing them to are 12kb (which is 12288 bytes btw, 1024 x 12). I tried a few of them but no luck. Any help would be appreciated because if it isn't something I'm doing wrong (ie the wrong value) then we are back to square one as your solution isn't a universal one.

UGH I thought we had this issue behind us.

If I had the file, I would happily tell you the exact size. I can easily find out again know. From memory it was '12000KB'.

However, my first test on using the brtly tool, the image was fine. Although I'm going to be creating two custom SNES WADs tomorrow so I'll see what happens.

The UNICODE function seems to be working as well. My Bare Knuckle III dump is fixed (doesn't say 'Streets of Rage 3' when I highlight icon channel).

12000kb is 12 megs, which would be insaine. That's why I asked.

Btw I think what you described is already setup in the padding function (as explained in the readme). If you put a "+" symbol in front of the byte size in the pad box it means "add this many bytes", but if you OMIT the "+" then it means "pad until the filesize equals this many bytes".

If I make the file this size according to Windows Properties: '11.7 KB (12,000 bytes)', it fixes the freezing problem.

I'll see if I can count how many hex bytes the file uses, that might help more.

EDIT:

In fact, check out the files yourself.

'banner1' is what the vcbrlyt edited. Images become corrupt.

'banner2' is the file that I padded a bunch of 'FF' hex bytes at the end. The images display fine.

 

[HowardC]

Freezing problem? Is that a typo? I thought we were talking about a corrupted image problem.

Man you really don't know how to follow the scientific method do you?

We should be working with super mario bros with the title chagned to "Super Mario Bros. 12345678" as that is the one I can't get to fix. Also changing the padding from "00" to "FF" is out of no where. There are too many variables in this test to prove anything but I'll see what I can do.

For future reference guys, this is how you setup a test to determine if padding is working.

1. Find a stock brlyt that without padding displays fine when you simply re-save it in the brlyt editor (without any padding).
2. Keep adding characters to the title entry until the banner corrupts.
3. NOW we start messing with padding to see if it fixes anything.
4a. If we can get padding to fix it then we try the same method on another brlyt corrupted in the same manner.
4b. If it doesn't then we can only conclude that either there is a bug in the brlyt editor, or that padding doesn't work 100% of the time.

I am by no means trying to be pushy, because I can't do this without you guys' help, but what I've outlined is the most scientific way to determine what is going on.

With that being said, I'll run the values you've given me through the brlyt and see what happens. Pretty sure I've already tried 12000 bytes though.

 

[HowardC]

Ok, after all that lecturing I think that data may have been enough anyway.

I remade the Super Mario Bros. 12345678 brlyt from the stock one (just in case there was corruption) and adding 12000 bytes seems to have fixed the problem!

Let me explain what I did:

1. Tried Super Mario Bros. (stock) without padding..... no corruption (as expected)
2. Tried Super Mario Bros. 12345678 with 12000 padding .... no corruption (yay!)
3. Re-edited Super Mario Bros. 12345678 to have a console entry of "Nintendo Entertainment System 2" to change the length, still no corruption.
4. Re-edited super mario bros. 12345678 to have it's original text, still no corruption with the extra 12000 bytes of padding.
5. Re-saved the edited banner.bin, just with lz77 compression... still no corruption.

So what that tells us, is at least in this case, 12000 bytes worked great and worked regardless of the text included, which suggests that padding works! That isn't enough testing to confirm that 12000 bytes always work though so more testing is always appreciated and when you do run into a corrupted banner, you should mess with the padding and report results if you have the time.

Step 5 was very important because lz77 compression, like all lossless compression, works by writing repeating characters in shorthand. So our 1000+ bytes of repeating 00's get reduced to a few bytes that say "repeate 00 for 1000 bytes" which is a prefectly acceptable amount of extra data.

Anyway, long story short 12,000 is at the least confirmed to work better than the random amount I set, so expect a new brlyt release in a few min with the padding set to 12000 by default. I'll look into the save injector as well. I haven't released it yet because I'm trying to find something that could cause those automation errors someof you are getting.

**edit**
New brlyt editor is up.... I'm looking into the save injector as we speak.

**edit 2**
New Save Icon injector is up as well.... the only thing I could see on the Icon injector that is different is that is sets some of the text in the forms 2.0 objects as it's loading. I turned that off to see if there is any change. In all honesty though, if it is an error with the program itself, it might not be one I can fix as I can't replicate the error on my machine.

And with that, I go back to working on the rom injector.

 

[marioxb]

Ok, after all that lecturing I think that data may have been enough anyway.

I remade the Super Mario Bros. 12345678 brlyt from the stock one (just in case there was corruption) and adding 12000 bytes seems to have fixed the problem!

Let me explain what I did:

1. Tried Super Mario Bros. (stock) without padding..... no corruption (as expected)
2. Tried Super Mario Bros. 12345678 with 12000 padding .... no corruption (yay!)
3. Re-edited Super Mario Bros. 12345678 to have a console entry of "Nintendo Entertainment System 2" to change the length, still no corruption.
4. Re-edited super mario bros. 12345678 to have it's original text, still no corruption with the extra 12000 bytes of padding.
5. Re-saved the edited banner.bin, just with lz77 compression... still no corruption.

So what that tells us, is at least in this case, 12000 bytes worked great and worked regardless of the text included, which suggests that padding works! That isn't enough testing to confirm that 12000 bytes always work though so more testing is always appreciated and when you do run into a corrupted banner, you should mess with the padding and report results if you have the time.

Step 5 was very important because lz77 compression, like all lossless compression, works by writing repeating characters in shorthand. So our 1000+ bytes of repeating 00's get reduced to a few bytes that say "repeate 00 for 1000 bytes" which is a prefectly acceptable amount of extra data.

Anyway, long story short 12,000 is at the least confirmed to work better than the random amount I set, so expect a new brlyt release in a few min with the padding set to 12000 by default. I'll look into the save injector as well. I haven't released it yet because I'm trying to find something that could cause those automation errors someof you are getting.

**edit**
New brlyt editor is up.... I'm looking into the save injector as we speak.

**edit 2**
New Save Icon injector is up as well.... the only thing I could see on the Icon injector that is different is that is sets some of the text in the forms 2.0 objects as it's loading. I turned that off to see if there is any change. In all honesty though, if it is an error with the program itself, it might not be one I can fix as I can't replicate the error on my machine.

And with that, I go back to working on the rom injector.

Both tools work for me now!! Thanks!

 

[HowardC]

good to hear.

I've started to clean up the rom injector somewhat (although atm it only does neogeo). I went ahead and added the ability to select zipped roms (or rared or whatever) as 99% of the roms out there are zipped up. I've also made the interface to look like the one for the u8 tool. Originally I was going to make it work like injectuwad, but I decided against it as that interface is terribly inefficient (roms have to be in the same folder, ect....). I should have some sort of release ready by this weekend!

btw... anyone know where I can get some info on the nes rom injection process? Pretty sure the rom is inside the 1.app and that's fine, I just need to know the starting address.

**edit**

Nevermind about the nes stuff, I figured it out.

For those who are curious... here is the proper way to inject nes roms.

1. Search in the 1.app for "NES" and hex value "1A", which is the start of the nes rom header.
2. After you've found the header, slots 5 and 6 represent the number of 16k and 8k banks respectively
3. Take the value in slot 5 and multiply by 16384
4. Take the value in slot 6 and multiply by 8192
5. Add the values found in steps 3 and 4 together and add 16 (the header size). We now have the size of the rom contained in the 1.app!
6. Inject the new rom by removing the data between the beginning of the header and the value found in step 5 and replacing it with the rom data.

This way you can inject a nes rom of any size without the need for padding!