News:

11 March 2016 - Forum Rules

Main Menu

Bomberman 5 Menu Translation

Started by DackR, July 05, 2012, 06:29:14 AM

Previous topic - Next topic

DackR

Okay. so I've been messing around with Bomberman 5, and I've finally figured out how text is displayed in the menus. I was able to partially hack the battle menu to display in english, but i'll probably need to do some asm work to fix the broken bits.

Here is a quick preview.

The font is compressed and surprise, surprise- the existing english characters are an incomplete set. (hence: conpig= no "f" yet lol) The small/large font pairing happens because of some funky bank switching.

Ugly, I know-- but better than nothing for now. I'm so damn tired. bah.

Auryn

Why not overwrite the graphics of the japanese font with an english alphabet??

KingMike

I tried hacking that once, it was a real mess. I forget the details now, though.
All I remember is that if it was easy, I'd probably have put out a patch by now. :)
"My watch says 30 chickens" Google, 2018

reyvgm

To make an F just delete the last line of an E.

burn_654

I would look to see if the game uses any uncompressed tiles in its code...perhaps you could insert your own uncompressed font?

Space might be a problem (it's always a problem...)

DackR

Quote from: Auryn on July 06, 2012, 12:18:09 PM
Why not overwrite the graphics of the japanese font with an english alphabet??
:) As KM said, it's a mess. I can not just overwrite the font because I've yet to figure out where it is stored. ...compressed font=wherever it is, it looks like garbage in the ROM.
I only knew that certain letters were missing and how they were arranged by looking at the uncompressed font in a savestate file. Compressing it and reinserting it would be a huge pain because I don't know how it compresses the gfx.

Quote from: reyvgm on July 06, 2012, 01:13:30 PM
To make an F just delete the last line of an E.
lol... here is the result of that... (only possible because of the way text is stored, but I can use top/bottom halves of different letters) Not a final solution. -_-'


Quote from: burn_654 on July 06, 2012, 01:21:46 PM
I would look to see if the game uses any uncompressed tiles in its code...perhaps you could insert your own uncompressed font?

Space might be a problem (it's always a problem...)
This could actually be a valid suggestion. If I could find a place to store an uncompressed font, is there anyone who would want to do the ASM work to bypass the compression for the font?? :) Pretty please? I know the sprites for all the different bombers are uncompressed. In fact, they may be the only gfx in the entire ROM that isn't compressed.

Quote from: KingMike on July 06, 2012, 12:23:16 PM
I tried hacking that once, it was a real mess. I forget the details now, though.
All I remember is that if it was easy, I'd probably have put out a patch by now. :)
Any chance you would consider a joint hacking venture? I've always wanted to pick your brain about this kinda stuff.

Auryn

Well I think I found the battle option font in the rom.
On the left side you have all the japanese letters and on the right side OFF and MAN can be seen giving you an idea in how it's stored.


I believe a bit below there is the main font for the game but I didn't get to be viewed correctly or almost correctly. Anyway I am not sure if it's a real compression or just a special format of storage.
Looking at some objects in 4bpp mode, they look fine but it's like they have a big shadow with the same shape just below.
Last time i saw something like that, was a font that used what Crystaltile 2 call "GBA3 Xbpp".
You can find how it works HERE
I hope i am correct and my information is usefull.

Ryusui

Yeppers. It looks compressed. Fortunately, it doesn't look like a difficult compression scheme - it's probably some flavor of RLE.

For the record, I wrote a graphics decompressor for Jiro Akagawa's The Sleep of Witches in Python, so if you're familiar with any kind of programming at all, implementing a codec should be trivial.
In the event of a firestorm, the salad bar will remain open.

DackR

:) Thanks for responding guys.

Quote from: Auryn on July 07, 2012, 02:46:19 AM
Well I think I found the battle option font in the rom.

I believe a bit below there is the main font for the game but I didn't get to be viewed correctly or almost correctly. Anyway I am not sure if it's a real compression or just a special format of storage.
Looking at some objects in 4bpp mode, they look fine but it's like they have a big shadow with the same shape just below.
Last time i saw something like that, was a font that used what Crystaltile 2 call "GBA3 Xbpp".
You can find how it works HERE
I hope i am correct and my information is usefull.
I will take a look at this right now. I've never even heard of the tile editor you are using.  8) Been a while since I did this sort of thing. Since you are using a GBA codec, I think it is possible that it is some form of RLE, LZ77, or Huffman compression as these are pretty common on GBA titles. I shall probably need to study this a bit more. If you have any other finds to share, I appreciate it very much!

Quote from: Ryusui on July 07, 2012, 02:59:13 AM
Yeppers. It looks compressed. Fortunately, it doesn't look like a difficult compression scheme - it's probably some flavor of RLE.

For the record, I wrote a graphics decompressor for Jiro Akagawa's The Sleep of Witches in Python, so if you're familiar with any kind of programming at all, implementing a codec should be trivial.
OMG. I bet you are right! I would appreciate it very much if you could send me the source code for this. I've not used python much, but I'm used to c++, php, and C#, so if it's similar, I think I can handle it. Thanks so much for your input on this.

Ryusui

Well, the code won't be of much help to you - I'm just saying "you can write a (de)compressor in just about anything." It would have to use the exact same RLE scheme - and for the record, no two RLE implementations I've seen have been exactly alike. If this were a GBA or DS game, it'd be a different story: those systems have LZ decompression algorithms written into the BIOS, so if a game for either one uses compression at all, it'll probably be the scheme that the system has built-in decompression for.

Anyway. RLE is a simple way of encoding graphics - the general idea is that graphics tend to use long strings of the same bytes in sequence (think large areas of solid color or transparency), so they have a mechanism for indicating a byte to write and how many times to write it. Solving a compression scheme like this is a matter of figuring out how the compression scheme differentiates compression codes from "plaintext" (regular bytes to output without modification), and how exactly the compression codes translate to graphics data. Mind, it could also be some form of the aforementioned LZ compression, which is a little more sophisticated: instead of compression codes indicating a byte to write and how many times to write it, they indicate how far back in the plaintext to look for the next sequence of bytes and how long it is. That is, if there's a lot of data being repeated over and over in the uncompressed graphics (also a likely situation), then the compression scheme is designed to replace the repeated instances with a code indicating to copy what comes next from somewhere earlier.

The important thing to keep in mind is that compression is just a code, and it can be cracked - it can be even easier than a newspaper cryptogram as long as you understand what you're looking at, because it gives you a partial solution right off the bat (as you've noticed already, there's easily-visible "plaintext" among the encoded data). A good way to start is, naturally, to compare the compressed and uncompressed data - especially the visible plaintext.

(Oh, and for the record, "plaintext" isn't necessarily text! It's cryptography jargon referring to unencoded data.)
In the event of a firestorm, the salad bar will remain open.

DackR

Okay... I've done a little more poking around... Apparently there was another section of the font that I hadn't found before that gets loaded into VRAM in different parts of the menus. These other sections do not make the english font available at all. I'm still able to change them, just not for the purposes of translating... So being able to edit the font is now essential. Damn.  ;)

Quote from: Auryn on July 07, 2012, 02:46:19 AM
Well I think I found the battle option font in the rom.
I've tried totally overwriting that section that you found and it doesn't effect anything in the menus. I'm not sure what that font is for yet...

Quote from: Ryusui on July 07, 2012, 03:44:35 AM
Well, the code won't be of much help to you - I'm just saying "you can write a (de)compressor in just about anything." It would have to use the exact same RLE scheme - and for the record, no two RLE implementations I've seen have been exactly alike. If this were a GBA or DS game, it'd be a different story: those systems have LZ decompression algorithms written into the BIOS, so if a game for either one uses compression at all, it'll probably be the scheme that the system has built-in decompression for.
I wrote a font editor for Little Master back in 2006. I no longer have the source code for that portion of my editor, so my thought was that I could take a look at yours and get reacquainted. No big deal, it's not necessary. Little Master's font was not in a very complicated format (I seem to recall it being in 2bpp 8x16 where one "color" represented the 8x8 top of the tile and another "color" represented the bottom, a third "color" for where each 8x8 had intersecting pixels and the final "color" was the background.) I expect that Bomberman is using some type of LZ compression(judging from your description). I am not all that familiar with these compression techniques.

Quote from: Ryusui on July 07, 2012, 03:44:35 AM
The important thing to keep in mind is that compression is just a code, and it can be cracked - it can be even easier than a newspaper cryptogram as long as you understand what you're looking at, because it gives you a partial solution right off the bat (as you've noticed already, there's easily-visible "plaintext" among the encoded data). A good way to start is, naturally, to compare the compressed and uncompressed data - especially the visible plaintext.
Thanks for the tip. I appreciate it.

Auryn

CrystalTile 2 is manly for NDS hacking but I love it and I use it for many systems.

Anyway, here is the part where i believe the actual font starts, you can make out a M, N, Z by scolling around sometimes numbers and naturally many japanese characters:


I don't know if you have tried but there are alot of sprites that can be viewed well with Tilemolester in 4bpp planar, composite (2+2bpp) mode but sadly not the font because I pretty sure it's not a 8x8:

DackR

Thanks Auryn! That's definitely the compressed font! I did already know about the sprites as I mentioned in an earlier post, but it's all good. One step closer!

bluecar5556

Me and my friends are serious about bomberman 5 and play it on my xbox 360 using SNES360 emulator but none of us are programmers, unfortunately.  I'm confused, was there only a partial translation due to the english alphabet not being available to start with?  It would be nice to have a translation to write to an actual SNES rom and play 4 player natively in 16 bit glory!  0_0  If the BIOS decrypts gfx encryption on games and is the same for all SNES consoles, isn't there already a decompressor used to translate other SNES titles, namely RPG's?

VicVergil

Quote from: bluecar5556 on October 23, 2013, 02:30:28 AM
0_0  If the BIOS decrypts gfx encryption on games and is the same for all SNES consoles, isn't there already a decompressor used to translate other SNES titles, namely RPG's?

The compression/decompression routines are NOT the same in SNES games.
There is no panacea, universal solution for all games.
AFAIK, Nintendo didn't give with their dev kit for the SNES a general compressor, like Sega did on Megadrive (Nemesis compression, though some games like Monster World IV don't use it), or like GBA and DS games (LZ compression, though once again it didn't keep some publishers from using their own compressions, I even saw a CPK one in a Japan-only Zelda clone by EA).

(Dat necrobump O_o )

KingMike

Quote from: bluecar5556 on October 23, 2013, 02:30:28 AM
Me and my friends are serious about bomberman 5 and play it on my xbox 360 using SNES360 emulator but none of us are programmers, unfortunately.  I'm confused, was there only a partial translation due to the english alphabet not being available to start with?  It would be nice to have a translation to write to an actual SNES rom and play 4 player natively in 16 bit glory!  0_0  If the BIOS decrypts gfx encryption on games and is the same for all SNES consoles, isn't there already a decompressor used to translate other SNES titles, namely RPG's?

If multiplayer is all you want, Bomberman Party Edition for PS1 is REALLY similar. (though single-player in that game was limited to a remake of the first NES game)
"My watch says 30 chickens" Google, 2018

bluecar5556

Ive emailed Svambo who translated bomberman 4 back in 2009 if translating bm5 uses the same methods using SNESEDIT.  Thanks for the PS1 game suggestion, ill definately check it out.

svambo

Hi Leader, hi Craig,
thanks for your kind mails. Bomberman 4 had no compressed charset so the code is different for Bomberman 5. However the way the text is stored might be similar. It's quite a while back but I  remember that there was more than one way texts were stored. The menus were texts and yes I used snesedit for them. Many other texts were sprites and every letter took 6 Bytes for position and sprite-block - was a lot of work to edit.
I uploaded you some notes I made back in the days. If you want check them out to get an idea.
http://www.file-upload.net/download-8296013/super-bomberman-4.doc.html
Good luck with your project.
Greets Svambo

FreeLunch

Not sure if you're still working on this project, but saw this and figured it was relevant (links to this thread).

http://bittask.com/topic.php?id=4631