- Joined
- Nov 14, 2008
- Messages
- 78
- Trophies
- 1
- Age
- 40
- Location
- England
- Website
- www.backloggery.com
- XP
- 301
- Country
If you pronounce Holo/Horo properly, it doesn't matter which one it is. As for the confusion with the Japanese Ls and Rs, the English L and R are very similar - that's where the confusion comes from. In other languages, like Spanish, L and R are very different so the "fault" is actually with the English language having developed so that there's little difference between the two sounds.
Anyway, really looking forward to this. I've just got the first novel so I'm sure I'll be a big fan of the franchise soon.
Anyway, really looking forward to this. I've just got the first novel so I'm sure I'll be a big fan of the franchise soon.
I don't want to sound pushy, this is purely a suggestion and not expectation. I was just wondering if we could get monthly updates saying "we are working on this and we are this% through" and maybe add somehing indicating if progress is smooth or if u ran into something slowing u down or if u guys have been swamped and couldn't do mug that month or what.
Not needed just asking.
Thank you for your time
Not needed just asking.
Thank you for your time
ragDOLLfun said:
To be completely honest with you, not much work is being done on the translation RIGHT now, since my translator seems to be busy/working on other translation projects right now.
Don't worry - the project isn't dropped by any means... But weekly/monthly updates at this stage wouldn't really be that useful, since not much is happening xD
I'm going to bug her a few more times, since she probably just needs to get motivated to work on it. If all else fails, I can ask my other translator
Again, don't worry guys XD
I plan to work on this a little more than I have been doing thus far. For the most part, anyways. It should go a little brisker.
- Joined
- Sep 27, 2009
- Messages
- 49
- Trophies
- 0
- Location
- Sunny California
- Website
- Visit site
- XP
- 100
- Country
I saw this the other day and all I can say is looks fantastic!
I have never heard of this series before, but any fan translation is always good in my book
Keep up the good work.
I have never heard of this series before, but any fan translation is always good in my book
Keep up the good work.
Thanks for the support guys!
A few more script files have just been translated/edited - I sent them to jjewel so she can try inserting them.
There's still a LOT more to go, but just letting people know that some progress is being made xD
I would make some sort of progress video but:
- The recording function in my emulator doesn't work for some reason.
- I should probably leave that kind of thing for when we have a larger portion of the game translated xD
A few more script files have just been translated/edited - I sent them to jjewel so she can try inserting them.
There's still a LOT more to go, but just letting people know that some progress is being made xD
I would make some sort of progress video but:
- The recording function in my emulator doesn't work for some reason.
- I should probably leave that kind of thing for when we have a larger portion of the game translated xD
Hi!!! I registered here just now for the sole purpose of telling you I really adore you for taking on this project! *__* I love Spice & Wolf, and was really looking forward to play at least one of the DS games dedicated to it. You have all my respect for the work you're doing!
May I ask you something? Do you also plan on releasing some tutorials/tools to extract/insert the text in the rom? I'm asking because as I'm not an English native speaker, and I would really like to translate the game in my own mother language.
But as I'm not really a programmer (I do have some experience with programming, but not really with file handling and encryption like in this case) and I wouldn't know where to start. So if you could publish some kind of tutorial that explains everything step by step you would really make a favour to everyone who wants to do such a thing!
Thank you very much and keep up the good work!!! I hope we'll be able to play this game soon!
(and now, I'll put this page into my "Favourites"!)
May I ask you something? Do you also plan on releasing some tutorials/tools to extract/insert the text in the rom? I'm asking because as I'm not an English native speaker, and I would really like to translate the game in my own mother language.
But as I'm not really a programmer (I do have some experience with programming, but not really with file handling and encryption like in this case) and I wouldn't know where to start. So if you could publish some kind of tutorial that explains everything step by step you would really make a favour to everyone who wants to do such a thing!
Thank you very much and keep up the good work!!! I hope we'll be able to play this game soon!
(and now, I'll put this page into my "Favourites"!)
Haseo-san said:
I'm still trying to figure out the codes in this game. (It's much more difficult than I thought.) Currently, scripts can be inserted with some manual calculations, but the current method only works for some specific scripts.
(I'm more confident with my manual hex editing than my programming skills, but I'll try to make a program if it's possible.
I for one joined GBAtemp purely to show support for you and this project. I don't wanna be some rabid internet dude, but I adore Spice and Wolf and the fact you are taking time to do this project pleases me greatly.
I'm not sure if you're still having problems with the control codes, but from what I've seen you should only have to update the following codes when you insert text:
First line of file = 4-byte data offset, 4-byte resource section offset, 8 bytes 0xFF.
D000XXXX = goto relative X (data offset -- 0x10)
CB00XXXX = first choice - goto relative X (data offset)
CD00XXXX = second choice - goto relative X (data offset)
(All the values are little endian)
You'll have to change the resource pointers when you change the speaker text, but inserting normal text won't affect it as long as you change the resource offset.
I had a play around with other codes (D1002E00 hides the speaker text, D1002F00 shows it). You can change the character image / speaker text displayed by changing 8800XXXX where X is the resource file number. It's the first value in each line: http://pastebin.com/W3abe5B9
First line of file = 4-byte data offset, 4-byte resource section offset, 8 bytes 0xFF.
D000XXXX = goto relative X (data offset -- 0x10)
CB00XXXX = first choice - goto relative X (data offset)
CD00XXXX = second choice - goto relative X (data offset)
(All the values are little endian)
You'll have to change the resource pointers when you change the speaker text, but inserting normal text won't affect it as long as you change the resource offset.
I had a play around with other codes (D1002E00 hides the speaker text, D1002F00 shows it). You can change the character image / speaker text displayed by changing 8800XXXX where X is the resource file number. It's the first value in each line: http://pastebin.com/W3abe5B9
Thank you very much, tehwes. Your information is very helpful. I figured the codes already but I didn't write them down like you did. It looked more comprehensible when you sorted them out like this.tehwes said:
(I also got D700XXXX as the indicators and the whole series of CA00 CB00 CD00 CE00 CF00 for another set.)
By the way, did you figure out the relationship for the number after the text codes? Like the ones after 5508 and 9510. Currently I used the bytes length and it seems to work fine for most of ASCII English alphabets. But once I mix Japanese text in it, the code gets mess up.
For example, in Japanese script, if you have 55 08 0E 1A, 5508 is the indicator for text, 1A is the length from text start to the beginning of the next code. But I have no idea how 0E got calculated. (It's not the number of character, not quite related to length of the text bytes either, but it really affects how the text shows up on screen.)
The regular one looks like this;
But some lines got misalignment like this;
(The 1st line of the original text is aligned to the left, but somehow it shifts to a little to the right in the game. I think it's because of the code that I still can't figure.)
I had a look at those text codes this morning (previously I just assumed it was a character count), and looks like it's to do with the control codes within the message.
^That seems to fit it AFAICT. I'm not sure if using single-byte characters will affect it or not. You might have to hardcode the dumper/inserter to pad until an even # of bytes (with a ASCII space?).
Anyway, give it a try.
EDIT: so yeah, it's simply the character count with a few extras. I changed 9510XXXXYYYY to XXXX=04, and it loaded 4 dual-byte characters (in JP). Then overwrote the dual byte characters with heaps of single-byte 'a's... and still only loaded 4 'a's. So make that "YY/2" into "char_count" instead, I suppose. I don't really know if that extra 1 still applies with single-byte chars. Will just have to test and find out.
Code:
5508 sample values
XXYYÂÂÂÂÂÂÂÂXX-(YY/2)ÂÂÂÂcodes within string
1626ÂÂÂÂÂÂÂÂ3ÂÂÂÂÂÂÂÂÂÂÂÂ1 new line,81a5
2542ÂÂÂÂÂÂÂÂ4ÂÂÂÂÂÂÂÂÂÂÂÂ2 new line,81a5
223EÂÂÂÂÂÂÂÂ3ÂÂÂÂÂÂÂÂÂÂÂÂ1 new line,81a5
1222ÂÂÂÂÂÂÂÂ1ÂÂÂÂÂÂÂÂÂÂÂÂ(none)
0C16ÂÂÂÂÂÂÂÂ1ÂÂÂÂÂÂÂÂÂÂÂÂ(none)
111EÂÂÂÂÂÂÂÂ2ÂÂÂÂÂÂÂÂÂÂÂÂ(none)81a5
9510 sample values
XXXX YYYYÂÂÂÂXXXX-(YYYY/2)ÂÂÂÂcodes within string
A200 3201ÂÂÂÂ9ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ7 new lines,(81a5)*4 (including one at end)
4F00 9200ÂÂÂÂ6ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ4 new lines,(81a5)*2 (including one at end)
Therefore...
XX=(YY/2)+(0D0A_count)+1
XX=XX+1 if ends on 81a5 (look for 81a50000, maybe?)Anyway, give it a try.
EDIT: so yeah, it's simply the character count with a few extras. I changed 9510XXXXYYYY to XXXX=04, and it loaded 4 dual-byte characters (in JP). Then overwrote the dual byte characters with heaps of single-byte 'a's... and still only loaded 4 'a's. So make that "YY/2" into "char_count" instead, I suppose. I don't really know if that extra 1 still applies with single-byte chars. Will just have to test and find out.
Thank you very much tehwes. I may have time to check on the files this weekend. I'll see what else I can find out.
P.S. There are a few dialogs that used codes such as @. For these codes, regular byte counts for the number after 5508 and 9510 will not work. (I added some blank spaces to the text and somehow the output came out right. But I am not sure how exactly it works out.)
P.S. There are a few dialogs that used codes such as @. For these codes, regular byte counts for the number after 5508 and 9510 will not work. (I added some blank spaces to the text and somehow the output came out right. But I am not sure how exactly it works out.)
Ok, I've revised my earlier analysis.
-0x00 counts as 1 character (!)
-Mostly the strings will have 1-5 of these at the end (padding), which DO count towards XX/XXXX. This is why you can be 1-5 short on your character count and it might not affect anything.
-All strings must have an even byte count. Pad with 0x00 (and add to the character count).
-You can simply count each New Line (0x0D0A) as 2 characters.
-0x81A5 is counted as 1 character (it is single character in SJIS, after all)
-In all strings with codes like "@", they are just read as single ASCII characters (11 in that case).
-They also use 2-byte spaces (0x8140) at times, which you may want to watch out for. It's slightly bigger than the ASCII space.
So yep, the thing messing me up was the 00s at the end. I did note at one point that some strings had more 00s at the end than others, but naturally I then forgot about it.
I tested it and it worked on all various messages -- in different files, with/without @ codes in them, with 9510/5508, and with mixed ASCII text.
-0x00 counts as 1 character (!)
-Mostly the strings will have 1-5 of these at the end (padding), which DO count towards XX/XXXX. This is why you can be 1-5 short on your character count and it might not affect anything.
-All strings must have an even byte count. Pad with 0x00 (and add to the character count).
-You can simply count each New Line (0x0D0A) as 2 characters.
-0x81A5 is counted as 1 character (it is single character in SJIS, after all)
-In all strings with codes like "@", they are just read as single ASCII characters (11 in that case).
-They also use 2-byte spaces (0x8140) at times, which you may want to watch out for. It's slightly bigger than the ASCII space.
So yep, the thing messing me up was the 00s at the end. I did note at one point that some strings had more 00s at the end than others, but naturally I then forgot about it.
I tested it and it worked on all various messages -- in different files, with/without @ codes in them, with 9510/5508, and with mixed ASCII text.
Thank you very much, tehwes.
I already sent suruz one version of the program earlier. I'll wait for the report on how it works and I'll update the program. It might take a while since suruz seems to be a bit busy now.
I already sent suruz one version of the program earlier. I'll wait for the report on how it works and I'll update the program. It might take a while since suruz seems to be a bit busy now.
Similar threads
