The level up stat screen in FE6

[gringe]

There are two different level up stat screens in FE6. One appears when you have animations on and the other when they're off. The one I'm having trouble with is the one that appears when animations are on.

Looking in the hex, none of this text appears to have pointers (they start at 1C9FF1 by the way). It's just taken directly, it seems. This area of the ROM allows for only two characters per stat, which is the problem.

Does anyone know how to change this? Can anyone help at all? This is one of the major inconsistencies left by the old patch and it would be great to fix this for the new translation patch.

Sorry if this belongs in the questions subforum, but I'm not really sure.

[Aleph]

1C9FF1.

Really?

That's not text. It's not even 4-byte aligned so it's probably not anything, but if it were text it would be referenced by the huge array of text pointers that are all contiguous later in the ROM (on that note: read the doc, it says these kinds of things).

Did you mean 0x081C9FF0? Are you talking about graphics? Why would there be a text pointer to image data?

[gringe]

Maybe I had some terminology wrong but I'm quite sure this is text. The current level up screen has strength as "SR" and this is the only instance of 82C482C2 in the ROM (not to mention all the other stats follow it). I'm not talking about graphics.

By the way I tried changing the text at 1C9FF1 to a pointer for A29B10 where I wrote "Str" but that didn't work. It just turned it into a heart.

EDIT: There are a lot of spaces that are essentially unused in the table. There are about a million ways to write hearts for example, but I don't think the hearts are used anywhere in the game. I wonder if changing these hearts into "double letters" (IE not just the letter "l" but "ll") would be a feasible solution. I've seen this used in some other ROM hacks before.

Edited March 6, 2014 by gringe

[gringe]

All right, so I've done some experimenting and found some things.

1. The pointer exists only for HP but includes all the stats.

2. Each stat can only be two characters.

I think combining letters in unused spaces in the font to get all the stats into two "characters" will be the best way to do this. Can anyone help me with editing the font?

[gringe]

Apparently the technical term for this is multi-tile encoding. It seems I'll need to do an ASM hack to get this working but all sources say it's the easiest ASM hack one can do. Still, does anyone who already knows what they're doing think they can help? I'll learn if I have to but needless to say a lot could go wrong.

[MP2E]

Apparently the technical term for this is multi-tile encoding. It seems I'll need to do an ASM hack to get this working but all sources say it's the easiest ASM hack one can do. Still, does anyone who already knows what they're doing think they can help? I'll learn if I have to but needless to say a lot could go wrong.

You don't need to do an ASM hack, you just need to replace the 2 tiles with tiles that happen to have 3 letters pre-rendered in them. I could assume that one character will be cut down the middle. Most GBA graphics are stored as LZ77 data so just try to decompress the pointer at the address used with an LZ77 graphics decompressor and see where it takes you. It should give you one of the letters. From there, you can create new tiles with a tile editor(there are tons) and then reinject into the free space after you LZ77 compress it. From here, just repoint the data. Most likely, there will be 2 adjacent pointers to the first and second letter.

You'd store prerendered tiles as a seperate table referenced only for the respective stat needed, of course. It wouldn't take much space :P

ASM hacking might be nice, but if you're going to go there, you may as well change the layout to allow more than 2 tiles, in the first place. The only problem I can see with that, is that you would need to move all of the data located in the ROM after each character address, to account for more characters. Is there a utility written to repoint FE6 data?

I'm not familiar with the Fire Emblem GBA hacking scene, but I am familiar with ASM and general hacking. If I were provided with a disassembly of the current level up character drawer I could probably hack something up :P

EDIT : Whoop just noticed you already figured out the pointers. Tile Editor

Edited March 13, 2014 by MP2E

[Lamia]

I don't know much about FE6 stuff, but the formatting of the letters is something I recognize from my FE4 travels, the text codes I've nearly memorized

if there's only one pointer for all of the stats(weird but not impossible), have you tried just changing that pointer and making your own list of the stat letters

that is, if you've already been successful in changing individual letters (it seems to use the same exact letter codes as j2e's FE4 if you need a list)

[gringe]

I don't know much about FE6 stuff, but the formatting of the letters is something I recognize from my FE4 travels, the text codes I've nearly memorized

if there's only one pointer for all of the stats(weird but not impossible), have you tried just changing that pointer and making your own list of the stat letters

that is, if you've already been successful in changing individual letters (it seems to use the same exact letter codes as j2e's FE4 if you need a list)

Yeah, there's a a space of 00 between each stat so I thought that maybe I could put in as many letters as I wanted as long as I have a 00 after each stat, but it didn't work. It definitely has a two-character limit per stat, or it all gets messed up.

I'm going to try using an LZ77 decompressor like MP2E suggested when I have time. If I understood what he meant correctly, that should be exactly what I need.

[Aleph]

Now that I think about it some more, Huffman compressed text probably doesn't have to be 4 byte aligned. It wouldn't be raw, though.

That would mean either the text already had an assembly hack applied to be loaded as raw text, which would make sense since I'm pretty sure Twilkitri helped with the translation patch (and made the original text hacking tools for that purpose). It sounds like you changed it and confirmed that it was actually affecting what was displayed as well. I vaguely remember locating a second system for loading and displaying text independent of the usual so maybe that is what is being used, although it doesn't explain why the text isn't aligned (a compiler would make it aligned) or why it's in such a weird location (a compiler would likely put it in a big pile of other data; having such a low address for text data is weird).

I supposed it's also possible that the stuff not making sense is an extension of the translation hackers being good at translating and inexperienced with software engineering.

As expected, there is no reference to that mis-aligned address. There is, however, a reference to 0x081C9FEC, which is the address of 2 (shift-JIS?) characters followed by a single 0 byte (which delimits several more 2 byte character pairs thereafter, including the one you mentioned in your first post).

The reference is at 0x0805D384, a low address that is likely in the midst of assembly code as I suggested (although this might not really be a "second text system" so much as "yet another case-specific text system" of potentially many). Kind of a weird thing to hardcode considering the stuff they didn't but okay IS.

[MP2E]

Now that I think about it some more, Huffman compressed text probably doesn't have to be 4 byte aligned. It wouldn't be raw, though.

That would mean either the text already had an assembly hack applied to be loaded as raw text, which would make sense since I'm pretty sure Twilkitri helped with the translation patch (and made the original text hacking tools for that purpose). It sounds like you changed it and confirmed that it was actually affecting what was displayed as well. I vaguely remember locating a second system for loading and displaying text independent of the usual so maybe that is what is being used, although it doesn't explain why the text isn't aligned (a compiler would make it aligned) or why it's in such a weird location (a compiler would likely put it in a big pile of other data; having such a low address for text data is weird).

I supposed it's also possible that the stuff not making sense is an extension of the translation hackers being good at translating and inexperienced with software engineering.

As expected, there is no reference to that mis-aligned address. There is, however, a reference to 0x081C9FEC, which is the address of 2 (shift-JIS?) characters followed by a single 0 byte (which delimits several more 2 byte character pairs thereafter, including the one you mentioned in your first post).

The reference is at 0x0805D384, a low address that is likely in the midst of assembly code as I suggested (although this might not really be a "second text system" so much as "yet another case-specific text system" of potentially many). Kind of a weird thing to hardcode considering the stuff they didn't but okay IS.

And it gets more fun :P Shift-JIS is common in the Japanese Fire Emblem games so it wouldn't surprise me if it were pointers to that(I've found 2 variants + a table to direct tile data in Seisen No Keifu, from my translation efforts so far.. Why IS?)

EDIT: It is definitely Shift-JIS of some kind. Has a utility been written for the GBA games to handle this?

Edited March 15, 2014 by MP2E

[Aleph]

Handle in what sense?

[MP2E]

Handle as in dump the Shift JIS text and be able to reinject it. The asm has to be hand edited, of course. I'll take a look tonight and see if it happens to be one of the types of Shift JIS in FE4. The number of bytes per character indicates it should be a standard 2-byte encoding(vs 7-byte wide encoding) but sometimes there are variances in the format itself.

I'm not 100% on Japanese character encodings because I started learning them recently, and it doesn't help that I can't actually read it :P Thank god for Google Translate and collaboration. If anyone finds more knowledge on the Shift JIS format please post.

I realize the tiles don't need to be modified at this point but realizing which roman character points to which Shift-JIS character is necessary.

EDIT: Due to some unforeseen life circumstances, I can't look at it tonight. I will ASAP and post with more information

Edited March 16, 2014 by MP2E

[Lamia]

I can tell you that FE4's menu text uses 2-byte shift-JIS only, nowhere in the ROM is any text ever compressed (pretty sure), and it's definitely never weirdly organized in a fashion like the FE6 statscreen's data here

as for using the letters themselves, start with this listing that FE4's j2e patch uses, from my notes

[spoiler=menutext.txt]

this is the converted shift-jis that j2e did

these letters appear in gameplay menus

82A0 A
82A2 B
82A4 C
82A6 D
82A8 E
82A9 F
82AB G
82AD H
82AF I
82B1 J
82B3 K
82B5 L
82B7 M
82B9 N
82BB O
82BD P
82BF Q
82C2 R
82C4 S
82C6 T
82C8 U
82C9 V
82CA W
82CB X
82CC Y
82CD Z
82D3 (SPACE)
8341 a
8343 b
8345 c
8347 d
8349 e
834A f
834C g
834E h
8350 i
8352 j
8354 k
8356 l
8358 m
835A n
835C o
835E p
8360 q
8363 r
8365 s
8367 t
8369 u
836A v
836B w
836C x
836D y
836E z

82D0 %
82D3 (SPACE)
815B -
817B +
817C -
8169 (
816A )
8148 ?
8149 !

824F 0
8250 1
8251 2
8252 3
8253 4
8254 5
8255 6
8256 7
8257 8
8258 9

Default
8260 A
8261 B
8262 C
8263 D
8264 E
8265 F
8266 G
8267 H
8268 I
8269 J
826A K
826B L
826C M
826D N
826E O
826F P
8270 Q
8271 R
8272 S
8273 T
8274 U
8275 V
8276 W
8277 X
8278 Y
8279 Z

Edited March 16, 2014 by Lamia

[MP2E]

Strange, in the source code it lists that j2e had 3 different dumpers for the script formats. One was marked for dialogue and used an EUC file, one was standard Shift-JIS as verified by my text editor, and the third text was something called "Fixed Shift-JIS" that I can't figure out for the life of me what it is. I've thrown many encoding formats at it and it looks like garbage.

Any idea why I can't read it? And also, why on earth would j2e use an EUC file on one of the formats but not the others if it were all the same Shift-JIS format?

I'm 99% sure there are 3 different encodings in FE4.

EDIT: Some admittedly incomplete documentation I wrote based on the source

Definitely interested in hearing your input on this, because I feel like I'm missing something here. I'd like to figure out the "fixed Shift-JIS" format. The C code only takes me so far when I can't actually read japanese

EDIT2: Ah you have the roman to shift-jis table. thanks! Now we just need the GBA disasm.

Edited March 16, 2014 by MP2E

[Lamia]

Strange, in the source code it lists that j2e had 3 different dumpers for the script formats. One was marked for dialogue and used an EUC file, one was standard Shift-JIS as verified by my text editor, and the third text was something called "Fixed Shift-JIS" that I can't figure out for the life of me what it is. I've thrown many encoding formats at it and it looks like garbage.

Any idea why I can't read it? And also, why on earth would j2e use an EUC file on one of the formats but not the others if it were all the same Shift-JIS format?

I'm 99% sure there are 3 different encodings in FE4.

EDIT: Some admittedly incomplete documentation I wrote based on the source

Definitely interested in hearing your input on this, because I feel like I'm missing something here. I'd like to figure out the "fixed Shift-JIS" format. The C code only takes me so far when I can't actually read japanese

EDIT2: Ah you have the roman to shift-jis table. thanks! Now we just need the GBA disasm.

no idea what the 'fixed shift-JIS' is supposed to mean, but I CAN say that those parts of the game that use it (skill, objective, config, battleopts, battleopts2, menu, menu2, menu3) are coded to use direct-to-address pointers instead of a two-byte pointer table as with the character/class/item/etc data... but either way, it still uses the same shift-JIS symbol codes, it's just pointed differently

the majority of that stuff in that doc is about dialogue text, which is different, it follows a control code + symbol format to encompass the huge amounts of kanji as well as kana, while saving on ROM space (unlike shift-JIS) and furthermore, the text comes with a width table and isn't constrained by the 8x8 tile grid like shift-JIS

[spoiler=explanation]

just as example, 09 - 0F are control codes that essentially change the 'font' that is used for the following text...

09 AB 93 3B 8D 0A 32 2A 9E will show four symbols under 09 font, then three under 0A

doing this allows for 239 * 7 (1673) different characters for dialogue text maximum

just might be strange if you're coming from the GBA series since they coalesced it all (afaik) into one, compressed format, while the jugdral saga doesn't use any text compression

and as for that file you linked... you wrote it? or was it from somewhere else? dialogue coding in FE4 is pretty much completely cracked by now

Edited March 17, 2014 by Lamia

[MP2E]

Ahh I see. That makes a lot more sense. Yeah, I wrote the document myself because I had thought that the C source was all that was available. It's good to hear that the format is fully cracked, because that means less work towards making a polished translation. I wish I had looked harder now though, reinventing the wheel isn't fun x.x

/me looks up documentation