Hi newcomer here, just finished both SN 1 and 2 last month. I was wondering if the translation is still on going? I really like the, me and my friends play it, we downloaded sn 3 but only the first part is english, we will enjoy it much more if it was english
Hey guys ! yeah the projects is still going,
translation is still at85%
trimming lines is at 10%
As you can see it will take a while, we could speed up process if we found a programmer who can override the word limit each line has or if more people could start trimming . we also need a translator who can proofread preferably with knowledge in the games but its not really urgent.
The only person who can release the patch is oil so you will have to ask him
translation is still at85%
trimming lines is at 10%
As you can see it will take a while, we could speed up process if we found a programmer who can override the word limit each line has or if more people could start trimming . we also need a translator who can proofread preferably with knowledge in the games but its not really urgent.
The only person who can release the patch is oil so you will have to ask him
It would do them a great favour if you could help out on the project, otherwise you shouldn't be whining about how much you want to play it cause everyone else wants to too.
So how bout maybe a word of encouragement to them or just shut up and wait and stop pestering or needlessly bumping this thread?
Gee... i didn't know that it was wrong for a KID to ask, and how did you come up with the conclusion that I was whining? Oh and by the way I am trying to help, I literally have a book on how to understand japanese beside me. Not disrespecting anybody, but please before you type negative comments, please think twice.
I have been able to translate some lines and modify them to fit in the game. It's the least I can do to help. Is it okay if I tell some of my friends about this, as far as I know some of them know japanese.
You should concentrate on learning Japanese properly so that you learn at least 300 kanji and all the grammar stuff. You're just getting started learning a difficult language. I'd love then to ask for your help in other projects of mine, but until then you'd delay the project a bit further (no offence) since the translation/ review process will be even longer than with a fluent Japanese speaker.
This game doesn't have furigana over the kanji, so you'd have a hard time for sure.
Plus they have already translated most of the text in-game (inserting it back is another story, though, and it's a hard and time-consuming process they can't do anything about it.
This game doesn't have furigana over the kanji, so you'd have a hard time for sure.
Plus they have already translated most of the text in-game (inserting it back is another story, though, and it's a hard and time-consuming process they can't do anything about it.
What you're looking at probably isn't so much 'overriding' anything as just updating pointers to the starts of each line to match new lengths. I can probably help, but depending on the format it might be a pain (vastly moreso if it's interspersed throughout the code rather than purely a couple of pointer arrays - could be either or a mix for all I know so far about Haji in particular.) I'd be a lot more inclined to put effort into it if the effort was a little more public in terms of results; at least making the raw text files from the translation so far available so they can be further worked on and finished even if this doesn't reach completion before everyone currently involved drops it (as many fan translation attempts do not, seen that far too many times.) What's your current script inserter written in, anyways? And do you have any clues as to where the pointers are stored (or any clear indicator it's not a pointer-based system? That would be HIGHLY unusual in my experience, if so...) Right now I gather you're just working off where the text was found and making start/length assumptions based on null string terminators or the like? Or do you know where the pointers are and just need to relocate the entire script to new space at the end of the ROM? If I write code for this I'd be wanting to make it public so people can use it in anything related (other languages, SCS2, etc.) I'd also be more inclined to work on this if there was a more convenient way to connect with you guys - a forum or translation site I use for nothing else isn't very good for that, and I can't use the translation site chat anyways since I don't allow Javascript. Any alternatives, IRC or email maybe?
I really appreciate your help! the person who made the tools to insert the script is oil_ , the project's lead, so you may want to contact him, as he undestands more about this than me
you may contact him sending him a PM http://gbatemp.net/members/oil_.332738/
or at sntranslation.vacau.com. We have a chatbox there you may use to talk to him.
Regarding the text limit, while going through the ROM with an quick 32bit search, I was able to find a couple of offset Binary addresses (0x00395D0-0x00395A80) that sets the value of where the text is placed based on a X and Y axis Hexdecimal value key. The results were inconclusive as it was DMO'd, but I was able to find that the IDs repeat themselves a lot, showing that the Hex's follow patterns, so I may be able to come up with something more useful given more time.
Also while researching scripts that were relevant with how GBA ROM's were made I found this:
Which were close to the set up of:
18 3E 48 4C 57 4C 35 0E E4 BC B6 B1 AE B6 C9 F2
19 43 46 4D 50 49 39 0E E2 C2 B7 AE AC B4 C5 F4
21 40 4E 52 4E 4A 35 07 DF C0 B2 B0 AF B3 CB F9
23 40 4D 53 50 4B 32 06 DA BF B2 AC B2 B7 D0 F7
21 3E 4D 56 4E 4A 31 04 D9 BD B3 AA B2 B7 D0 FB
26 40 4C 57 4F 45 34 00 D6 BC AF AB B2 BF CF FF
27 44 4D 53 50 45 2B FA D6 BF AF AE B0 BC D4 FE
2B 40 51 4F 52 44 2A FD D3 C0 AD B0 B1 B7 D7 03
2D 46 4E 51 50 46 23 FA D4 BD B3 AC B0 B9 DA 04
These being related when I set it to DOS/ASCII only, but then again this may all lead to dead ends...
[Sorry about the long message]
Also while researching scripts that were relevant with how GBA ROM's were made I found this:
Code:
int main(void)
{
int x, y, blockX, blockY, loop; // variables
// process input
if(!((*KEYS) & KEY_UP)) // they pushed up
blockY--; // subtract from y (move up)
if(!((*KEYS) & KEY_DOWN))
blockY++;
if(!((*KEYS) & KEY_LEFT))
blockX--;
if(!((*KEYS) & KEY_RIGHT))
blockX++;
// draw the picture
for(y = 0; y < 160; y++)Which were close to the set up of:
18 3E 48 4C 57 4C 35 0E E4 BC B6 B1 AE B6 C9 F2
19 43 46 4D 50 49 39 0E E2 C2 B7 AE AC B4 C5 F4
21 40 4E 52 4E 4A 35 07 DF C0 B2 B0 AF B3 CB F9
23 40 4D 53 50 4B 32 06 DA BF B2 AC B2 B7 D0 F7
21 3E 4D 56 4E 4A 31 04 D9 BD B3 AA B2 B7 D0 FB
26 40 4C 57 4F 45 34 00 D6 BC AF AB B2 BF CF FF
27 44 4D 53 50 45 2B FA D6 BF AF AE B0 BC D4 FE
2B 40 51 4F 52 44 2A FD D3 C0 AD B0 B1 B7 D7 03
2D 46 4E 51 50 46 23 FA D4 BD B3 AC B0 B9 DA 04
These being related when I set it to DOS/ASCII only, but then again this may all lead to dead ends...
[Sorry about the long message]
A programmer hmm? My uncle studied IT, I'll try asking him if he can do it as a favor.
I'm the guy that made the tools and the site, let me explain what I know about the game and what the problems are.
The game uses Shift-JIS with a little modifications. Characters are 16 bit, most of them are the same as in the shift-jis table. There are some exceptions that are characters that were unused in the game so they were replaced with special characters such as a heart and a paw. The rest of the exceptions are special characters that get replaced with the name your character's name and your guardian's name, etc.
There's 2 kinds of text in the game:
- Uncompressed short strings such as character names, weapons, messages, etc. They are all around the same area and are zero terminated. I dumped them with a script that looks for valid strings ended with 0 in that area, since most of the strings are contiguous most of them were dumped OK, but there's some things that were detected as strings even though they aren't. This part is already translated and most of the insertion works fine but there are some strings that cause trouble and I got to check them out when I have time.
- Compressed text from dialogs. This is where the problems are. The game's script is divided in more than a thousand "files" (there's no file system, they are just in the middle of the rom). Each one contains the dialog from a part of the game. Each one of the "files" is compressed with LZ77 and is located at the addresses you can see in the File column at the translation site. I got all these addresses from the script dump Ritchburn made years ago, but I was also able to find them and dump them on my own by looking for LZ77 compression headers in the ROM. Each one of the files contains a bunch of dialog lines surrounded by code the game interprets (I think this contains which character says each line and the expression they make, style of the characters, etc). Each actual dialog line starts with the bytes 0x08 0x03 and ends with 0x00 0x00, except for the first line of each file that doesn't have anything special to indicate the beginning. You can try extracting files with GBADecmp (other compressors/decompressors can't compress it back to its original size so they cause problems). The address of the first dialog file is 017bcb2c.
- Changing the length of a dialog line - Changing a line without affecting it's length works well, but trying to save a longer or shorter line corrupts the game. For shorter lines I just pad the remaining space with spaces, no problem here. I couldn't find any indicator in the code surrounding lines that holds the length of each line. Maybe it's there and I didn't see it, maybe it's in a different place outside of the dialog files or maybe it's something different.
- Putting the files back - Each dialog file must be compressed again with LZ77 after editing and put back in the same place. If lines are made longer files will be bigger after compressing them back and will overlap with other parts of the ROM corrupting it. This could be fixed by finding and replacing the pointers to each file and putting all the files after the end of the ROM. I wasn't able to find the pointers with a hex editor and couldn't find any debugger that works fine.
Right. I'll refrain from saying anything negative but please STOP asking everyone whom you think are helpful because your definition of being helpful may be a HINDRANCE for others! Having a Japanese book/Online translator without actually diving into a language in-depth will not help get any lines translated accurately. Moreover, asking your IT uncle would not help much unless he studied gaming type programming or worked for a gaming company as a programmer since this is an entirely different programming which requires you to match texts and not your simple everyday IF/DO/OR/READ/PRINT programming functions. Understand its really tedious and not even your uncle would want to do it unless hes paid.
If you really do want to help, please be like me and just support them by not doing anything. By supporting in the background, you'll realize its much more beneficial to them if you don't do anything or post any irrelevant things.
Oh boy. That's one of the more annoying ways to store it, though fairly efficient. Yeah, that's almost certainly neither pointer nor length based, aside from the LZ77 block's length and location itself - that 2-byte 0 at the end of each is probably the null terminator, and it's most likely using a variable command length opcode-based scripting system, for which that 0x08 0x03 is presumably the command to print null terminated text, with the implication that it ends with the 0. The good news is you probably won't have to deal with pointer math much except for relocating entire LZ77 blocks - you'll need to find the pointers to the data blocks, and if a data block needs to be moved to grow, move the block and change the pointer. What the game presumably does to actually use the data is decompress the entire block, then parse through it 1 or 2 bytes at a time, then does whatever the opcode it found dictates (which in the case of text is print everything up to the next 0x00 0x00 as dialogue.) The remaining question there is - is there only one entry point per 'file', or can there be multiple? Given the 'thousands' part, probably the first option, and that's gonna be a lot easier to deal with if so - if it's the later, there may be a pointer table somewhere to choose where to start processing opcodes. Another potential sticky bit is if they use jumps instead of skips for choices/etc: in which case there are probably offsets stored right after each jump opcode, and you'd need to update those if moving things. If it's simply 'skip x commands' or 'switch to dialogue file x', though, that won't care if you change the length of a command.
According to http://en.wikipedia.org/wiki/Shift_JIS both upper and lower-case roman character should only take 1 byte, but I've seen claims otherwise regarding Hajimari's encoding - what's up with that? Are they storing even those as 2 bytes in some abnormal way?
Is each 'file' LZ77'd as a single block, or only the text portions within it? (e.g. are the 0x08 0x03 opcodes compressed as well?) LZ77 being what it is, changing the content while keeping the same uncompressed length should still be quite capable of resulting in a different compressed length, no matter what you do, since it's dictionary-based and will vary results base on the degree of nearby self-similarity; something like "testtesttesttest" should compress much better than "This is a test."
The best way to go about this, albeit a fairly complicated one, is: Find both the pointers to and lengths of the LZ77 blocks (hopefully they're an array somewhere if not right next to/part of the LZ77 header itself in the case of the lengths; poke around the bytes immediately before it, and make sure you know what the contents of the header are; length may be there, or is it purely a signature and dictionary?) Then, when you recompress the blocks, if it's same or shorter length, you just write the length, or if it's longer, you need to move the block to free space at the end of the ROM. The first step here is probably going to be making sure you know exactly where each block starts, since looking for a pointer value that's e.g. 4 bytes later than you should would make it vastly harder. Did you try VisualBoyAdvance-1.8.0-beta3's debugger?
Within the blocks, once you're able to change the uncompressed size, you can probably simply move everything up or down to fit the new dialogue size, since the null terminator will implicitly tell it where the lines end (but beware that jump caveat I mentioned above; if it works for constant dialogue but breaks for things with choices or plot flag dependancies, that's probably why.) With a little more effort figuring out the dialogue opcodes you'd even be able to add or remove screens' worth of dialogue if needed - which you may need to do as well depending on how much the lengths change, does it auto-split too-long-for-one-window text in a single opcode into multiple windows worth?
I assume that offset is file-based - have you pursued finding out where it's loaded in memory? And is GBADecmp open-source?
That's a bit odd. Each file, when decompressed, starts with a shift-jis dialogue line that ends with 0x00 0x00 but doesn't start with an opcode? You're certain? There -should- be the usual opcode there plus an opcode before it to set portraits/etc if needed (pretty much any plot dialogue) in a typical system like this. Perhaps it simply starts with a DIFFERENT opcode?
EDIT: Further findings:
Did some googling on the GBA's brand of LZ, apparently the first byte is 0x10 signature, then 3 little-endian bytes for the uncompressed size (10EEh/4334d in this case,) which is consistant with your file offset; there's another small block right before it at 17bcb0c too which looks to have 'compressed' to larger than the actual data inside it, and I'm guessing the next blocks are 17BD14C (3A2Eh/14894d), 17BE5EC (ED2h/3794d) and 17BEAAC (229Ch/8860d), right? Do you know what's up with the "PSI3" that seems to end up coming a couple bytes later? Looks like more header but without digging out some source code I can't be sure yet. The byte in between might be a bitflag or something if the header is indeed more than 4 bytes. Anything else in the header COULD matter for resizing, or it might not... have to find out what it is to be sure.
Either way, it seems clear: The only size that's stored is probably the uncompressed size, and it's right there in the header; looks like this is a variant of LZ with no end-marker in the stream too, and sliding-dictionary only. To get the compressed size to see if you're over available space or not, you're going to have to keep track of it as you (de)compress.
There any particular reason your site seems to have the files in no particular order? It looks like actually finding the dialogue for 17bcb2c on it would be a matter of looking through all the pages by hand...? How would I find it to see what I'm looking at?
Also, it's possible they take the first line's print opcode as implied and put the first portrait/etc after, maybe, though I have to wonder if there's something funky going on there in the case of plot dialogue that starts with character movement instead of a print. Stuff like the first PC-Murno scene would have to have opcodes in there for the relevant animations, presumably.
Using VBA's memory viewer, I was able to confirm that 'first' block gets loaded at 0x097BCB2C in memory, which if the above is correct, means next block at 0x097BD14C, compressed size of the 2C block: probably 620h, including header; pretty good compression, but quite believable. It's also looking oddly like headers are always 16-byte (or possibly even 32-byte) aligned with a 12-byte offset, which may mean something (either they want the bit after the first 4 bytes paragraph-aligned, or there may be 12 or 28 more bytes of header before each block.
Figuring the remaining details out may help with figuring out where they stashed the pointers to these things, since we need to know which exact byte they're going to be pointing TO.
A link to some good clean C source code that handles the relevant decompression would be really nice if you have anything like that, BTW.
Great news guys! yesterday our translators finished translating the main story!
A big thanks to cakepans and salixa! (And send em cake too, they deserve it)
there is the proofreading and insertion left to go!
A big thanks to cakepans and salixa! (And send em cake too, they deserve it)
there is the proofreading and insertion left to go!
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
BigOnYa:
I haven't played my Switch n a month or so, just been playing Xbox, and just picked to play lil and Damn that A and B, X and Y being reversed always gets me. -
@
slaphappygamer:
I havent played my xbox360 is a couple of years. My switch got much use the last few days. Tears of The Kingdom is great+1 -
@
BigOnYa:
I agree Tears is great. I even played thru it completely twice. I've been hooked on playing thru Fallout 4 again though, after they released the next gen version for Series S/X. Is pretty cool update.
-
