ROM Hack Text Character Limit Issue in Translation

[Blazer]

Yo, I'm having this rather annoying issue where text gets cut-off due to a character limit and I'm unable to get a working fix for it. If anyone could help a bro out, it'd be appreciated. Note that I have little to no ASM skills myself and just make use of the programs other people make, really, so I'm not a great hacker or anything. :\


So to start... the problem I'm referring to is for the game Fire Emblem: Heroes of Light and Shadow, blog at http://www.heroesofshadow.net. To quote the original problem:

A slightly more pressing problem is this:

"2. Maybe less important, but it would be nice to expand the amount of text available in the text rewind. 39 symbols in a line isn't actually a lot. I checked the NA/EU version of FE11 and their text rewind has more space available. Perhaps you could work some magic like how you increased the text buffer space?

If not, I guess we could make do with a cut-off text rewind, as I'd rather not force the text into 39 characters per line. "

The text rewind is this part of the game: http://dl.dropbox.co...text_rewind.png

Happens in the dialog of a chapter when you press the... R button, I believe. The limit for that text is 39 characters (or so my fellow team-member says, I don't know if it depends on the actual pixel width of the characters themselves), so it gets cut-off, but that's really annoying since the graphical character limit in the actual text is greater and we'd like it to match. I honestly have no idea where to start here, but it'd be lame if we had to cut-off text to only use like 60% of the width of the box because of this.

Someone else (Nagato) then helped me but it wasn't completely fixed. Here's the patch source which was simply enough even for me to decipher:

; Game: Fire Emblem 12
;

.nds
.open "arm9.bin", "arm9-2.bin", 0x02004000

.org 0x02044A44
.db 0x37
.org 0x02044A58
.db 0x38
.org 0x02044B54
.db 0x38
.org 0x02044970
.db 0x38

So it has a base and then edits the data of the arm9.bin file at an offset calculated by essentially subtracting the base from the offset... knowing that it just changes 4 values to something higher, i.e. it adds 0x10 to each character limit (0x27-0x37, 0x28-0x38, thus increasing the limit by 16 characters). Supposedly it worked but upon loading the script a little bit past the first cutscene in the prologue, graphical and then game-freezing glitches appear. It should be obvious if you play it with Desmume but if you wish for me to make a video or screenshot it just let me know.

Thus I'm led to believe that something else is... interfering? Given that any value above the original value glitches the game, I'd say there might be data being overwritten or something, but I'm no hacker, just a guy with basic logic skills.

So the character limit itself seems to be fixed but in return a game-breaking graphical glitch appears. The higher the character limit, the earlier that text glitch appears, sadly: only at the default value of 0x27 (39) does it stop/work right.

Any help here? Here are the files necessary to play the beginning of the game (at least they should be): http://dl.dropbox.co...iles_021812.zip It's not the latest arm9.bin file but I can easily mimic it to the latest one after the problem here is fixed (I only made a small change between the old version and the new version and I'm not on my home computer or else I'd just post everything straight up). Thanks to anyone who takes the time out to read this or comment!

 

[StorMyu]

Increasing this limit is probably reserving space on the Vram, if you take too much Vram, you'll have graphical glitch that's unavoidable.
The only trick here would be to find some more space in Vram to send all your text to that another place.

That may not be helpful to you, but that's the only explanation that came to my mind.
Maybe Nagato could help if he already started, but it's as he wish ^^

Because you can't really fix that problem without any proper knowledge.

 

[Foxi4]

If the text is tiled then the character limit should not matter as the amount of tiles in VRAM should not change - the tileset remains the same, this patch only increases the area of the map that can be altered to show text.

My guess is that you're leaking memory somewhere - the increased map does not fully flush, ending up with chars stacking up in RAM, but I'm no hacker so I can only give you this suggestion as it makes sense to me.

I suggest checking the RAM and VRAM and OAM contents while the crashes and glitches occur, perhaps two tilesets overlap in space that should be reserved for something else, messing up other maps or causing them to in out-of-bounds due to lack of flushing.

 

[StorMyu]

If the text is tiled then the character limit should not matter as the amount of tiles in VRAM should not change - the tileset remains the same, this patch only increases the area of the map that can be altered to show text.

My guess is that you're leaking memory somewhere - the increased map does not fully flush, ending up with chars stacking up in RAM, but I'm no hacker so I can only give you this suggestion as it makes sense to me.

I suggest checking the RAM and VRAM and OAM contents while the crashes and glitches occur, perhaps two tilesets overlap in space that should be reserved for something else, messing up other maps or causing them to in out-of-bounds due to lack of flushing.

Leaking memory somewhere... ? Ram data "can't" technically causes graphical glitch as you have to load stuff from RAM then to Vram and if by any luck, the graphic is loaded before the text and THEN being overlap because you're "pre-loading" it, that's a really bad way of coding imho.
OAM data posess their own Ram adress which is not related to any of the Main User Ram, there's no way a bug between the text and the graphics can occur here.

About the game freezing one, yeah your argument make sense, the amount of text in RAM is probably overlapping something important. but if it's not a text problem (easy to check, just have to test without the little asm hack) then you'll have to debug why it's causing this glitch by looking what's happening before the freeze.
The only left is (as I said) the Vram,

 

[Foxi4]

Except the data in VRAM has to be loaded from somewhere. The graphics first go through RAM and if a particular section of RAM is locked out by data when the engine does not expect it, it may not overwrite memory in the address that was previously allocated and transfer the contents to VRAM as they are.

 

[Blazer]

tl;dr it's a big problem and not fun

and the solution seems to repoint something--I'm not sure what because between my lack of understanding of some of the grammar and lack of understanding of some of the hacking talk,I simply don't understand it--to space where the data won't overwrite anything. Meaning I need A) to find the pointer to this place and B) a new place in the... VRAM? to actually put it, which will be hard to find

so is anyone actually willing to help me or at least guide me? I'm always willing to put in the effort, but effort alone doesn't make up for knowledge, ability, or the talent to learn that knowledge and put it to use, which if I had I wouldn't be asking for help XP