can't get to view font tiles (or any tile)

[lean]

hello, after being succesful in hacking yuyuhakusho3(J) for gameboy (changing to english alphabet and translating), i decided to do the same with dragonball z goku gekitouden for game boy. For my surprise, when i tried to view the tiles with several tile editors (tile layer, tile molester, yy-chr, crystal tile 2, etc) i got a nonesense tileset, like if it was encrypted or compressed or something, couldn't get to see it properly. i needed to see and edit the tileset to replace the japanese alphabet for the english one, as the game doesn't load both of them during dialogs.

this is an example of what im able to see.



so i read that feidian could deal with the problem, but after installing php and all, i cant get feidian to work. i might be doing it wrong. this is what i type:

php.exe feidian.php -r 8,8,16,16,0x8000 dra.gb output


not sure about the "0x8000". anyway, when i tipe that it just shows me this screen:


help please?

[RedComet]

FEIDIAN isn't the tool you want to use if the font is compressed. You'll have to figure out the compression scheme and then write a decompressor and compressor for it.

[Ryusui]

Which means you need some programming skills in order to proceed.

Pretty much any language will work, really. And you can get the tools for free. The talent will have to come from you, though.

[Gideon Zhi]

Pretty much any language will work, really. And you can get the tools for free. The talent will have to come from you, though.

Okay, this is going to be somewhat tangential, but the word you're looking for is skill, not talent. Talent is something in-born. Bongo` is talented - he picked up 65816 incredibly quickly, and was doing crazy stuff with it within a year. Gemini is talented. Despite my catalog, I am *not* talented - I am simply skilled. I've practiced and practiced and pulled a lot of teeth, and over the years I've slowly gotten damn good at what I do, but it's been a very long process.

Sorry :/ This is just one of my pet peeves.

[Ryusui]

Apologies. I'd already said "skill" and I didn't want to seem redundant. Mea culpa.

[lean]

so there's no other way around it? i don't think i've got the knowledge to write a decompressor, as my programming skills are kinda VERY basic.

shouldn't it be possible to  replace one tile for another in a hex editor as the game does also have an english alphabet? it tried to do that. i ran the rom in visualboy and looked up the tiles addresses. then in windHex i went to the offset of the same number and edited the hex. the tileset got modified but not the right tiles. I think that tile addresses are not equal to the hex offsets, but how are they related? there seems to be some relation..

for example. if my tile adress is 0:8970, i'd change the hex line 8970-897F.

is that even kind of  near the subject?

thanks for your answers, btw.


EDIT: i kept reading on the subject and that solution was kinda improbable.

i found out that using no$gmb i can write a snapshot and then open it in any editor and view the tiles perfectly, edit them and save the file. when i open the snapshot back in no$gmb the tiles are as i saved them. sooooo
the question would be, is there a way to take the data from the snapshot and add it to the rom?

EDIT 2: nevermind,i'm pretty sure that the change is not permanent, just for a couple of screens apparently.

but still, no$gmb is able to take the rom, decompress part of it when it writes a snapshot and recompress it back when it loads the snapshot. there must be something i can do there without  having to program a tool. i only have BASIC language knowledge and basic actionscript, so i don't think i'm able to write such a piece of software, wouldn't know where to start. I'm really interested in this particular  game because there only exists a japanese version of it.

any recommendation?

[Nightcrawler]

i don't think i've got the knowledge to write a decompressor, as my programming skills are kinda VERY basic.

That *IS* the essence of the trade. You start being inadequate and you figure out how to do things and develop whatever skills you need to accomplish your goal. Gain more knowledge and work on improving your skills. That's all any of us can really do.

[lean]

ok, thanks. i'll probably give it a try after i finish my previous less ambitious project getting more experience and having more time to learn how to program such a thing.

[KingMike]

for example. if my tile adress is 0:8970, i'd change the hex line 8970-897F.

is that even kind of  near the subject?

No, that is just the CPU address for VRAM ($8000-9FFF) where it has been written.
It will require assembly-language skills to figure out how it got loaded from the ROM (which is mapped to CPU address $4000-7FFF) to VRAM.

[Klarth]

so there's no other way around it? i don't think i've got the knowledge to write a decompressor, as my programming skills are kinda VERY basic.

The easiest way is to get a copy of the font (or make one) and when the game decompresses and loads the original font...rewrite the code (should only be a couple assembly instructions) to not decompress and load your uncompressed font instead.  You just need to find enough room in the ROM to store that uncompressed copy.

shouldn't it be possible to replace one tile for another in a hex editor as the game does also have an english alphabet?

I'm not exactly sure what you mean by this.

i found out that using no$gmb i can write a snapshot and then open it in any editor and view the tiles perfectly, edit them and save the file. when i open the snapshot back in no$gmb the tiles are as i saved them.

This isn't actually modifying the game.  When you edit a snapshot/savestate, you're editing gameboy memory.  It doesn't actually recompress/decompress the data to the ROM.  Savestate editing sometimes can be a good way for testing things, but it won't affect the ROM itself.  The change isn't permanent because the game code reloads the original data later on (during a battle change or menu, etc).

[lean]

I'm not exactly sure what you mean by this.

what i mean is that the game i'm trying to hack has a japanese font, but also an english font wich is used in a couple of menus.
when i tried to hex hack the game's dialogs, i couldn't use english font tiles as the game doesn't call those when displaying dialogs, as far as i could understand.
what i tried to do was to replace de japanese font tiles with the english ones, so those would be the loaded ones during dialogs. i don't think THAT can be done as all the tiles are compressed.

The easiest way is to get a copy of the font (or make one) and when the game decompresses and loads the original font...rewrite the code (should only be a couple assembly instructions) to not decompress and load your uncompressed font instead.  You just need to find enough room in the ROM to store that uncompressed copy.

as there IS  an english font there. i wouldn't need to store a new font, i would only need to decompress and load the ENGLISH font.
i don't know asm, but i think i might be able to understand it if it's not a lot of lines to change. I'll probably check every document i find on the subject, but do you recommend some in special that could help me with this?


by the way, sorry about my english. it's not my native language.

[Klarth]

what i tried to do was to replace de japanese font tiles with the english ones, so those would be the loaded ones during dialogs. i don't think THAT can be done as all the tiles are compressed.

Right, you won't be able to replace them like that in the ROM.

as there IS  an english font there. i wouldn't need to store a new font, i would only need to decompress and load the ENGLISH font.

I'd recommend making a second font.  Using a menu font for dialogue is usually not ideal.  I don't do gameboy assembly work, so I can't recommend specific documents.  You will need a Z80 assembly reference as well as a gameboy hardware reference.  Grab a GB emulator with a decent debugger.  Learn how the gameboy loads and displays graphics...once you figure that out, it shouldn't be too hard.  There might be some open source GB demos so you can get an idea.  There are also documents that describe the technique, but applied to the SNES.  Such as http://www.romhacking.net/docs/381/

[Ryusui]

You mean BGB, right? Or does FCEUXD support GB and NES now?

[lean]

hello guys, as i started to check out the asm i got to hack the game in gameboy assembly editor. i searched for code that loaded the address 8000, so the first i find is "ld hl,8000" (and then called for what i think may be some loading and decomrpession of tiles function). i changed the 8000 for 8800 to see what happens. and for my sourprise, the game loaded some tiles that it didn't in that particular part of the game (a nintendo logo set of tiles).  in a hex editor i replaced some text for these tiles and then ran the game in no$gmb, and IT WORKED, the text was replaced for the newly loaded tiles (confirming that the tiles were now loaded).

but the thing that i don't understand is that, when i load the same rom in visual boy advance it doesn't load the tiles. it's kinda weird.. and don't really get why. but i think it might be an emulation problem because now i realize that this emulator doesn't show the nintendo logo at the first screen in the first place, and no$gmb does.

kinda weird if i think about it...
is the nintendo logo at the begining of games stored in the rom or in the emulator?

EDIT: anyways, i'll give that article a read..

[Klarth]

You mean BGB, right? Or does FCEUXD support GB and NES now?

Yeah, mixed them up.

[Sawakita]

hello guys, as i started to check out the asm i got to hack the game in gameboy assembly editor. i searched for code that loaded the address 8000, so the first i find is "ld hl,8000" (and then called for what i think may be some loading and decomrpession of tiles function). i changed the 8000 for 8800 to see what happens. and for my sourprise, the game loaded some tiles that it didn't in that particular part of the game (a nintendo logo set of tiles).  in a hex editor i replaced some text for these tiles and then ran the game in no$gmb, and IT WORKED, the text was replaced for the newly loaded tiles (confirming that the tiles were now loaded).

Editing random part of codes is not exactly a good manner of doing things. Consider that in your ROM there there are very likely more than one instance of "ld hl,$8000" so you might be editing the wrong one.
Anyway, excluding the option that you write your own (de)compressin tool, your other chance is this: overwrite the existing code (which decompresses fonts in Work-RAM and loads the result in VRAM) with a code that just loads uncompressed fonts from ROM to the original Work-RAM and than let that the existing program copies it to VRAM (so you don't have troubles with VBlank timings).

Obviously first you have to find and disassemble the original routine; to do this you'll need to use a debugger (I strongly suggest BGB). You can for example put a breakpoint on access to VRAM:8000 and see when the game stops right before loading fonts in VRAM, and then go disassembling.
Now, since I'm cool (and since I was curious), I gave a very quick look at your game's code (using BGB), and found out that fonts can be loaded either in VRAM:8000 or in VRAM:9000. Here is a small chunk of extracted code, just to help you starting out somewhere:

Code Select Expand


ROM4:7398 21 00 80         ld   hl,8000
ROM4:739b 18 03            jr   73a0
ROM4:739d 21 00 90         ld   hl,9000
ROM4:73a0 3e 40            ld   a,40
ROM4:73a2 cd de 10         call 10de
ROM4:73a5 c3 2a 07         jp   072a

So, now, all you have to do is put a breakpoint at 04:73a0 in BGB and figure out the code step-by-step to find what to modify. Also, notice that this game, like many japanese-version games, has very small free space, so you might need to expand the ROM and repoint fonts and parts of code in a different bank than the original.

kinda weird if i think about it...
is the nintendo logo at the begining of games stored in the rom or in the emulator?

The Nintendo logo is loaded by the Boot ROM, located in the Game Boy hardware.