Hacking VCFE Wip...

  • Thread starter Thread starter HowardC
  • Start date Start date
  • Views Views 140,188
  • Replies Replies 628
  • Likes Likes 2
RadioShadow said:
Beats of Rage? XD Well you do beat people up to the beat I suppose.

The small guide was on page 16. It's slightly out of date but gives you an idea on how it works.


That's a slip of the tongue... beats of rage is a very popular beat-em-up engine inspired from streets of rage. It's been ported to practically everything, including the wii.

SH&E: Well you'd have to investigate that sort of thing yourself. It's called try it and see what happens. I don't have time to muck about in the wii games atm. I can tell you that games are a different animal than vc/wiiware apps as they aren't made by nintendo and thus there are an infinate number of file types the various manufacturers choose to use.
 
HowardC said:
Mrkinator, SH&E:

While I appreciate your interest, right now all tools are beta and are only meant to be used by people familair with the banner editing process. I reccomend you wait until vcfe itself comes out, which will handle all settings itself. (Should be out before the first of the year.) Regardless, you should look at the original banner editing tutorial so you can get a grasp of what is involved and the dangers of editing banners if you don't know what you are doing. (It CAN brick your wii!!!) You are still welcome to try the tools though, just don't expect people to explain how they work for you.
wink.gif
I think radioshadow did a simple tutorial somewhere in this thread, but it got buried. Anyway, addressing your questions:

0.apps should extract just fine. A type mismatch would suggest that what you are trying to open isn't a 0.app, but without more info I wouldn't know.

There are 6 tools, each with a different purpose that work on different files. Each tool has a short description next to the download link and a readme file included. Chances are if you STILL don't know what the tool is to be used on then you shouldn't be using it.
wink.gif

(God, now I feel really noobish right now...lol
tongue.gif
)
-------------

Nevermind, it was the wad in the end, I injected it into another wad and the 0.app unpacked perfectly. I've done banners in the past with your tools but I'd never run across that before, that's why I asked
shy.gif


I realize the tools are still in beta, I've been following this thread for a while
biggrin.gif


And I did follow the original banner tutorial and Radioshadow's guide, that's how I figured this out
wink.gif
 
I tried the new u8tool and it's still not letting me unpack "LZ77_emanual.arc" from the PAL Castlevania III. The original file is 1026kb. After running the u8tool on it, I get "Run-time error '424' Object required" and then I get two extra files in the 05.app folder "LZ77_emanual.arctmp" and "LZ77_emanual.arcarc". The tmp file is the same size as the original and the arcarc file is 1194kb. I tried renaming it and extracting it, but I get another error.
 
marioxb said:
I tried the new u8tool and it's still not letting me unpack "LZ77_emanual.arc" from the PAL Castlevania III. The original file is 1026kb. After running the u8tool on it, I get "Run-time error '424' Object required" and then I get two extra files in the 05.app folder "LZ77_emanual.arctmp" and "LZ77_emanual.arcarc". The tmp file is the same size as the original and the arcarc file is 1194kb. I tried renaming it and extracting it, but I get another error.

hm Castlevania III PAL LZ77_emanual.arc seems to be in the same LZ77 format as the new japan VC games I have :\

00000000h: 11 0D FB 13 00 55 AA 38 2D 00 00 00 20 0B 00 00 ; ..û..Uª8-... ...
 
The hex '11' at the start means it's a different type of LZ77 compression is used. Just not sure which exact compession is used.

I have also found the location of where the data is to extend the title in the banner.brlytl. Just got to locate the exact location of the data but I know where abouts it is located thanks to a copy and paste of part of part of a data from a Commodore 64 banner.brlyt to a Genesis banner.brlyt. It's located above the Consoles title.

I need to have a look in more detail know.
 
marioxb said:
I tried the new u8tool and it's still not letting me unpack "LZ77_emanual.arc" from the PAL Castlevania III. The original file is 1026kb. After running the u8tool on it, I get "Run-time error '424' Object required" and then I get two extra files in the 05.app folder "LZ77_emanual.arctmp" and "LZ77_emanual.arcarc". The tmp file is the same size as the original and the arcarc file is 1194kb. I tried renaming it and extracting it, but I get another error.


As I stated, the new version doesn't let you extract the headerless lz77 archives, what it does is let you create them. The wii supports the various lz77 formats natively, so the new version allows you to create a headerless archive with the lz77 compression we use. As radioshadow stated, this type of archive uses a style of compression I'm unfamiliar with and thus we can't work with it yet.


RadioShadow:

I already have the position of the positional data for the console tab, we've actually discussed it a few times before, I just haven't implemented it because we've had so many problems with the brlyt editor. It would also take some cleverness to automagically stretch the tab to match the title as text entries are a variable width depending upon the letters used.


Anyway, I chimed in for an update. I've coded 3 of the 8 possible (yes I said EIGHT!) tg16 file formats in the rom manager and most of the rest are variants of the first three so it shouldn't be too bad. I just wanted to tell you all that so you'd realize why it's taking so long.
smile.gif
After that I have to actually let it run and make sure they are being copied/formatted/ect properly and if all goes well we should be ready for a very early ALPHA release. I still need to code in support for lz77 compressed roms though. Judging by what I've been seeing the compression is totally optional, but anything that saves space is a good thing in my book.
 
HowardC said:
RadioShadow:

I already have the position of the positional data for the console tab, we've actually discussed it a few times before, I just haven't implemented it because we've had so many problems with the brlyt editor. It would also take some cleverness to automagically stretch the tab to match the title as text entries are a variable width depending upon the letters used.

Including having a longer text title that doesn't move to the second line? Well that's great then!
biggrin.gif


Could an option be included to manually change it now that the brlyt editor is working correctly? I would like to make the Commodore 64 banner (used in the Panel De Pon WAD in the youtube video) the same size as the Super Famicom one (I used a EU one so the banner would contain the other languages).

The 'automagically stretch' feature could wait but the Japanese characters used a fixed width font so as a basic feature, it could stretch depending on the number of Japanese characters used. It would mean ASCII characters will leave a bit of a space (as they use different but smaller widths... I think) but would still fit inside the tab bar.

EDIT: Is there a way we can tell what font size the console name uses? That would make things easier.
 
Well yes japanese characters have a fixed width, but if I were to use the number of jap characters as a guide then english text would always end up getting cut off. Remember, there are two english characters for every 1 japanese one even if the english characters are generally narrower.

The font size and what not wouldn't be necessary. What you'd do is read the width of the text entry/tab in the brlyt, then divide that by the number of characters in the text. That'd give you a rough estimate of the width per charater and then you'd adjust the width's based on the number of characters added or subtracted. It would be by no means exact, but it is probably as close as we can get.

Right now I'm working on the rom manager. I'm not going to go back to anything else until the rom manager is out of alpha because it is difficult to work on and I don't need any distractions. We'll get back to it though.
smile.gif
I would love for you to experiment in the mean-time though to see if text width manipulation works and/or the type of measurement that is being used. That might be helpful when we are ready.
 
Can you post your notes on the locations? Otherwise I can't experiment! ^^'

And the images became distorted when I repacked a 'Streets of Rage' and 'Comix' Zone the icon.bin files but when repacking the 'Earthworm Jim' file, the images display fine.

I'll upload the files.
 
hey howard, remember the disorted images on banners with previous versions of your tools... i am afraid the new version gets the same result with homebrew channels... lz77 compressed or not. compressed leaves a black banner and white icons and without conpression it is disorted...
 
If i change an tpl of existing banner(none VC), like mario kart as an example, why the banner gets all fuzzy?
For sure the new tpl has the same name and same dimensions.

greets
 
It's due to the size of the banner.brlyt file that's causing the images to distort.

If you make sure the banner.brlyt file is 12000KB in size (just insert a bunch of hex data at the end of the file), that will fix the problem.

Or open the banner.brlyt with VC brlyt Editor, click on save and then repack the banner.bin file.
smile.gif
 
Well, as I've stated before, my tools are only geared towards vc archives, so the fact that they aren't working correctly on wiiware archives isn't suprising.

You should know the drill by now.... if you want me to figure it out you need to send the original, unedited archive as well as the one you created you are having trouble with.
 
i'll see if i still have the fuzzy one... btw, it wasn't wiiware but only homebrew channel...

edit: still have the fuzzy one, but not the icon white and banner black one... the original was a wad manager channel that worked perfectly...
 
FGOD said:
strange that a banner.brlyt file which isn't touched makes a banner/icon fuzzy or black/white

edit: i thought that problem was fixed...
tongue.gif


The problem is fixed, add the 120000 byts like radioshadow said and it fixes it. In 90% of your archvies simply unpacking and repacking DOES work. It isn't strange at all actually.... The best I can tell is the lz77 we use is extremely similar, but not identical to the one the wii uses. The wii can unpack our archives just fine, but in some cases buffering is needed to get it to partition the file correctly. It is why neogeo archives never worked after they were edited.
 
RadioShadow said:
RadioShadow said:
Can you post your notes on the locations? Otherwise I can't experiment! ^^'

Damn you FGOD for distracting HowardC from my post!
tongue.gif


It's already mentioned in this thread (don't ask me where).
I don't have the specifics off the top of my head, but positional data is stored in the entires at the beginning of the brlyt, (with the color) the tab itself is the "PF" entry while the text is "PFLine" despite the fact that one is a texture and the other is text the positional info works the same way.
 

Site & Scene News

Popular threads in this forum