ROM Hack Big Windup! DS Game English Translation?
- Thread starter Slade_Wind
- Start date
- Views 639
- Replies 4
Never heard of the game and don't know if it has a following either as a game franchise (I find football boring but can at least see the appeal of Inazuma Eleven, most other non Nintendo non Kunio kun Nekketsu sports titles having an uphill struggle) or from some anime/manga (not always the most reliable of translators/you don't want to know how many dragon ball ? fans have attempted projects and gone nowhere).
Japanese games featuring Roman alphabet is nothing unusual at all, though without checking the blank character you have highlighted there seems to encode as 20h which is ASCII for space which is somewhat unusual (most Japanese games if they feature such things will only do it in the 16 bit ranges). Altered a font, especially on a DS if your game uses the NTFR font format (the format Nintendo provided for such things, not used in all games but enough to truly note), is nothing too drastic though and most of the effort will be in editing graphics (possibly those menus, and if not then the two characters several of those are will throw you into fiddling with tile maps) and editing text (the ntfr actually providing the encodings for you which is nice, but still will have pointers and any markup/placeholders to contemplate).
Japanese games featuring Roman alphabet is nothing unusual at all, though without checking the blank character you have highlighted there seems to encode as 20h which is ASCII for space which is somewhat unusual (most Japanese games if they feature such things will only do it in the 16 bit ranges). Altered a font, especially on a DS if your game uses the NTFR font format (the format Nintendo provided for such things, not used in all games but enough to truly note), is nothing too drastic though and most of the effort will be in editing graphics (possibly those menus, and if not then the two characters several of those are will throw you into fiddling with tile maps) and editing text (the ntfr actually providing the encodings for you which is nice, but still will have pointers and any markup/placeholders to contemplate).
No one knows how close because it's a DS game so it's not getting localized, it's not famous enough to have a remaster port that could be localized, and no one knows how much work would be required since no one started working on it.
I am glad that you picked up tinke to start digging through the game, I can see there is a folder called script, maybe that holds the text, you can start analyzing the files inside.
Oh no you guys misunderstood my wording, sorry. The way I was trying to say it was that I WANTED to do the translating and from what im seeing in those picks it looks... doable? Its bizarre. Is it possible that once all those kanji symbols were laboriously and after much difficulty, translated properly, would that display all the textboxes I showed in English? And not having to fiddle with hex editor? Or no?
Like I had a slight interest in attempting to turn it into English at the very least.
Post automatically merged:
Sorry. Here, take a look at an English character and then a Japanese one.
Attachments
There are four elements in editing text and thus translating a game.
1) Making sure there are the characters you need to do it, aka editing the font. Not necessarily the easiest aspect in some things (if you are doing a variable width font adaptation, 8 bit text conversion or expanding things in many older titles).
2) Editing any graphics. Not all text is text, which is to say some text is stored in a graphical format (icons in the world above shops in RPGs, anything that would be described as word art, some aspects of menus on occasion, title screens...). For some puzzle games this can be an entire game if it is mostly a menu you have.
3) Figuring out the baseline encoding of the initial game. Games don't necessarily use the common PC encodings of text (ASCII, shiftJIS, EUCJP, unicode...) and often do their own thing. Was getting less by the time of the DS but still far from unknown or only partially compliant with standards, or having a few custom additions.
4) Pointers. Games don't have the time to be decoding text and figuring out where the endings of things are. To that end the vast vast majority of games will use something called pointers. I usually liken them to the contents page of a book, which is to say if you stuff a bunch of pages in (think longer sentence) or take some out (shorter sentence after translation) then the stupid computer is not going to know this and just dutifully decode where the text says to go.
For DS games I usually find the pointers in the file with the text, or a helper file in the same directory. Said puzzle games and menus might also skip pointers in favour of fixed length. Any text in the binary (ARM9.bin and overlays) will likely use the memory as a baseline rather than files like everything else. Files might start counting at the start (normal pointers), might be a matter of pointer location plus value at said location (relative, usually first noticed when the pointers appear to be 4 more "out" of what they should be each time, and offset where they start counting somewhere within the file (usually the end of the pointers/start of the text proper).
The NTFR (nitro font resource I believe) is as mentioned the format that Nintendo gave devs the option to use with the dev kit. Fewer use it than the likes of the SDAT sound format, indeed it is most commonly seen in Nintendo first party titles. Some particularly annoying games might only use it for a portion of the text within the game and use something else for other things.
However it can be a mighty boon for several of those aspects described above -- it will showcase the character and what it decodes as leaving you mere to transcribe it (hope you know some Japanese, though do be aware that Japanese programmers are as lazy as any other so they might borrow and ordering from shiftJIS, EUCJP, do it as order the characters appear in a game, commonness of characters, order they appear in whatever standardised test was given either when the game was new or during their school years...) rather than necessarily having to do the more traditional methods (though there might be some of that for placeholders and markup). Similarly it is laughably easy to add new characters compared to many other games/formats where such a feat is likely to need someone that can code in the relevant assembly format. With text being decoded easily it should also become apparent where the end of sections is which can help with pointers (list of said end of sections compared against the presumed pointer field tends to reveal a lot in a hurry).
That said it is not the whole story and there is a not insignificant amount of work to do both to extract what it has (some of which will be manual, or maybe OCR if you are lucky (DS fonts are not usually of a resolution that plays nicely, especially not for Japanese).
1) Making sure there are the characters you need to do it, aka editing the font. Not necessarily the easiest aspect in some things (if you are doing a variable width font adaptation, 8 bit text conversion or expanding things in many older titles).
2) Editing any graphics. Not all text is text, which is to say some text is stored in a graphical format (icons in the world above shops in RPGs, anything that would be described as word art, some aspects of menus on occasion, title screens...). For some puzzle games this can be an entire game if it is mostly a menu you have.
3) Figuring out the baseline encoding of the initial game. Games don't necessarily use the common PC encodings of text (ASCII, shiftJIS, EUCJP, unicode...) and often do their own thing. Was getting less by the time of the DS but still far from unknown or only partially compliant with standards, or having a few custom additions.
4) Pointers. Games don't have the time to be decoding text and figuring out where the endings of things are. To that end the vast vast majority of games will use something called pointers. I usually liken them to the contents page of a book, which is to say if you stuff a bunch of pages in (think longer sentence) or take some out (shorter sentence after translation) then the stupid computer is not going to know this and just dutifully decode where the text says to go.
For DS games I usually find the pointers in the file with the text, or a helper file in the same directory. Said puzzle games and menus might also skip pointers in favour of fixed length. Any text in the binary (ARM9.bin and overlays) will likely use the memory as a baseline rather than files like everything else. Files might start counting at the start (normal pointers), might be a matter of pointer location plus value at said location (relative, usually first noticed when the pointers appear to be 4 more "out" of what they should be each time, and offset where they start counting somewhere within the file (usually the end of the pointers/start of the text proper).
The NTFR (nitro font resource I believe) is as mentioned the format that Nintendo gave devs the option to use with the dev kit. Fewer use it than the likes of the SDAT sound format, indeed it is most commonly seen in Nintendo first party titles. Some particularly annoying games might only use it for a portion of the text within the game and use something else for other things.
However it can be a mighty boon for several of those aspects described above -- it will showcase the character and what it decodes as leaving you mere to transcribe it (hope you know some Japanese, though do be aware that Japanese programmers are as lazy as any other so they might borrow and ordering from shiftJIS, EUCJP, do it as order the characters appear in a game, commonness of characters, order they appear in whatever standardised test was given either when the game was new or during their school years...) rather than necessarily having to do the more traditional methods (though there might be some of that for placeholders and markup). Similarly it is laughably easy to add new characters compared to many other games/formats where such a feat is likely to need someone that can code in the relevant assembly format. With text being decoded easily it should also become apparent where the end of sections is which can help with pointers (list of said end of sections compared against the presumed pointer field tends to reveal a lot in a hurry).
That said it is not the whole story and there is a not insignificant amount of work to do both to extract what it has (some of which will be manual, or maybe OCR if you are lucky (DS fonts are not usually of a resolution that plays nicely, especially not for Japanese).
Similar threads
- No one is chatting at the moment.
