Translation Question
- Thread starter Spikeman
- Start date
Ugly Joe
New member
> I'm trying to translate a game from Japanese and in the
> section I'm working on the Japanese names take up alot less
> space then the english ones is there any way to make more
> room to add in the translations? (I know about pointers and
> stuff).
What kind of space are you talking about? Do you mean you need to fit six tiles into a space only four tiles wide, or do you mean that there isn't enough space in the rom to fit all the longer names?
> section I'm working on the Japanese names take up alot less
> space then the english ones is there any way to make more
> room to add in the translations? (I know about pointers and
> stuff).
What kind of space are you talking about? Do you mean you need to fit six tiles into a space only four tiles wide, or do you mean that there isn't enough space in the rom to fit all the longer names?
Gil-Galad
New member
It also helps to know what system the game is run on like SNES or NES for example. With SNES it's sometimes easy to get more space. With NES you have to work with the bank you're in or map to another bank in the rom or add a bank to the rom which requires a bit of work.
Pointers are usually the best option because you just optimize the text in the space given. Also you can implement compression in a rom which is a lot of work. For instance you can install a DTE/Dictionary scheme in the rom. This is the most simple compression for text. DTE is Dual Tile Encoding. How this works is that you drawl 2 characters at one time instead of one. This is a benifit because you only use 1 byte for 2 characters. When that particular DTE byte is written the code looks at a lookup table and prints whatever is there. Dictionary encoding is the same way except that you print more then 2 characters. Sometimes you can even print a substring to the screen.
This is about all I can tell you without knowing what you're working with.
Pointers are usually the best option because you just optimize the text in the space given. Also you can implement compression in a rom which is a lot of work. For instance you can install a DTE/Dictionary scheme in the rom. This is the most simple compression for text. DTE is Dual Tile Encoding. How this works is that you drawl 2 characters at one time instead of one. This is a benifit because you only use 1 byte for 2 characters. When that particular DTE byte is written the code looks at a lookup table and prints whatever is there. Dictionary encoding is the same way except that you print more then 2 characters. Sometimes you can even print a substring to the screen.
This is about all I can tell you without knowing what you're working with.
The ROM I'm working on is for the GBA (the game is Rockman.EXE 4.5). The section I'm trying to translate is the names of the battlechips (kinda like spells or something if you have never played it). I know about pointers and optimizing with them but the thing is that in the english versions of the name almost every single one takes more space then the japanese one. So optimizing in the space giving won't work. So I'm thinking I will either add space to the ROM (if you can do that on GBA) or try and implement a DTE encoding thing (I worked on FF1 for NES which uses DTE so I know the basics but not how to implement). Any advice on where to get info?
I mean there isn't enough space in the ROM to fit the longer names. I already know the english names because I have played the english version of other games but this one was never released in the US. I'm translating the easy stuff first because I don't really know that much Japanese but I am learning.
Ugly Joe
New member
> I mean there isn't enough space in the ROM to fit the longer
> names.
You're probably best off trying a DTE hack, then. If you don't know how to do it, I can find an article on it, but it will be for the NES. The concept is the same, but the asm for the hack would obviously have to be different.
> names.
You're probably best off trying a DTE hack, then. If you don't know how to do it, I can find an article on it, but it will be for the NES. The concept is the same, but the asm for the hack would obviously have to be different.
Ok thanks but do I need to learn asm for this? I already know asm for the computer so it shouldn't be too hard learning it for the GBA right?
> You're probably best off trying a DTE hack, then. If you
> don't know how to do it, I can find an article on it, but it
> will be for the NES. The concept is the same, but the asm
> for the hack would obviously have to be different.
> You're probably best off trying a DTE hack, then. If you
> don't know how to do it, I can find an article on it, but it
> will be for the NES. The concept is the same, but the asm
> for the hack would obviously have to be different.
Ugly Joe
New member
> Ok thanks but do I need to learn asm for this? I already
> know asm for the computer so it shouldn't be too hard
> learning it for the GBA right?
Yeah, if you want to do a DTE hack (or a rom expansion) you will need to know some asm. I learned DTE from http://www.emuxhaven.net/~kingmike/romhelp/dtecode/dtehelp.htmKingmike's tutorial</a>, but I was hacking an NES game, so it may not be as helpful to you. He gives the asm source for his hack at the end, but that's 6502 asm. You need to write the asm code that does pretty much the same thing, only in the asm that is used by the GBA (which eludes me at the moment...).
I'm not sure how much else of that article will apply to GBA games, but read it and understand exactly what it is that the DTE hack does. It may not tell you how to add the hack, but should be able to explain to you what it is you should be trying to do.
> know asm for the computer so it shouldn't be too hard
> learning it for the GBA right?
Yeah, if you want to do a DTE hack (or a rom expansion) you will need to know some asm. I learned DTE from http://www.emuxhaven.net/~kingmike/romhelp/dtecode/dtehelp.htmKingmike's tutorial</a>, but I was hacking an NES game, so it may not be as helpful to you. He gives the asm source for his hack at the end, but that's 6502 asm. You need to write the asm code that does pretty much the same thing, only in the asm that is used by the GBA (which eludes me at the moment...).
I'm not sure how much else of that article will apply to GBA games, but read it and understand exactly what it is that the DTE hack does. It may not tell you how to add the hack, but should be able to explain to you what it is you should be trying to do.
Ok maybe I'll try adding DTE to an NES game before I try this out on the GBA. I skimmed the tutorial and the asm is different then the one I know (z80) so I'll have to learn that. I know this could take awhile but if I get it to work it will be worth it. Thanks for all your help. I just have one last question: Would it be any different to add MTE instead (more than two chars)?
EDIT: I tried to find some docs on gba asm but the only thing I could find was the name of the language: ARM7TDMI. Anyone know where I can find any info on this?<P ID="edit"><FONT class="small">Edited by Spikeman on 08/02/05 07:57 PM.</FONT></P>
EDIT: I tried to find some docs on gba asm but the only thing I could find was the name of the language: ARM7TDMI. Anyone know where I can find any info on this?<P ID="edit"><FONT class="small">Edited by Spikeman on 08/02/05 07:57 PM.</FONT></P>
Ugly Joe
New member
> Thanks for all your help. I just have one last
> question: Would it be any different to add MTE instead (more
> than two chars)?
Yeah. With a DTE hack, there is a byte that gets set to 1 after the first of the two characters is read, and set back to 0 after the second of two characters is read. This value of this byte is used by the hack to do two things:
1) It tells the hack to read the first or second byte out of the DTE table value.
2) It tells the hack to tell the game whether or not to advance to the next byte in the script.
So basically, the game's script hits a DTE value, the hack kicks in and processes the DTE value. Since the byte is set to 0, it will read the first byte out of the table, set the byte to 1, and tell the game not advance the script. The game's script will then hit the same DTE value, the hack will kick in again and this time read the second byte out of the table since the byte is set to 1. It'll then set the byte back to 0 and the script resumes as usual.
If you want to use MTE instead, you'll have to change the way this byte works.
If you go with some other fixed length (like, each value in the table will be four bytes instead of two bytes, etc) you can just change the hack so that it doesn't advance the script until the byte equals 4 or 5 or whatever length you use.
The other, more likely option, would be to not use a fixed length. This way would require a bit more ingenuity on your part. There are lots of ways that you could do it, but I would try to do it this way. I would have two tables instead of just one. The first one would be a pointer table. The DTE values in the game's script would be used to lookup a pointer in this table. The pointer from the table would then be used to lookup the actual value that's assigned to the DTE value (located in the second table). Each value in the second table would be ended with some kind of control byte so that you could tell when it ended. Every time the hack gets called, it would check for the value of the next byte in the second table. If that value is equal to the control byte, it would tell the game to advance the script, otherwise it wouldn't (so that the hack will keep getting called until the word in the second table is done). In this case, the 0 or 1 byte from the DTE hack would only be used to keep track of which byte in the word to display (in other words, it would be incremented with each call of the hack, used as an offset, and reset to 0 when the word is finished).
That's how I would do it, but there are certainly plenty of other ways to go about it.
> question: Would it be any different to add MTE instead (more
> than two chars)?
Yeah. With a DTE hack, there is a byte that gets set to 1 after the first of the two characters is read, and set back to 0 after the second of two characters is read. This value of this byte is used by the hack to do two things:
1) It tells the hack to read the first or second byte out of the DTE table value.
2) It tells the hack to tell the game whether or not to advance to the next byte in the script.
So basically, the game's script hits a DTE value, the hack kicks in and processes the DTE value. Since the byte is set to 0, it will read the first byte out of the table, set the byte to 1, and tell the game not advance the script. The game's script will then hit the same DTE value, the hack will kick in again and this time read the second byte out of the table since the byte is set to 1. It'll then set the byte back to 0 and the script resumes as usual.
If you want to use MTE instead, you'll have to change the way this byte works.
If you go with some other fixed length (like, each value in the table will be four bytes instead of two bytes, etc) you can just change the hack so that it doesn't advance the script until the byte equals 4 or 5 or whatever length you use.
The other, more likely option, would be to not use a fixed length. This way would require a bit more ingenuity on your part. There are lots of ways that you could do it, but I would try to do it this way. I would have two tables instead of just one. The first one would be a pointer table. The DTE values in the game's script would be used to lookup a pointer in this table. The pointer from the table would then be used to lookup the actual value that's assigned to the DTE value (located in the second table). Each value in the second table would be ended with some kind of control byte so that you could tell when it ended. Every time the hack gets called, it would check for the value of the next byte in the second table. If that value is equal to the control byte, it would tell the game to advance the script, otherwise it wouldn't (so that the hack will keep getting called until the word in the second table is done). In this case, the 0 or 1 byte from the DTE hack would only be used to keep track of which byte in the word to display (in other words, it would be incremented with each call of the hack, used as an offset, and reset to 0 when the word is finished).
That's how I would do it, but there are certainly plenty of other ways to go about it.
> I would have two tables
> instead of just one. The first one would be a pointer
> table. The DTE values in the game's script would be used to
> lookup a pointer in this table. The pointer from the table
> would then be used to lookup the actual value that's
> assigned to the DTE value (located in the second table).
I see what you mean, if you use fixed length you don't need a pointer table because you can get the offset from the table by multiplying the control byte. (Sorry if I say it in a confusing way but that is just how I think).
> Each value in the second table would be ended with some kind
> of control byte so that you could tell when it ended.
Would that really by necessary? Couldn't you just find where it ends by using the pointer table? It would save space in the long run.
Right now I'm having problems finding any info on assembly for the GBA any idea where I could find that?
> instead of just one. The first one would be a pointer
> table. The DTE values in the game's script would be used to
> lookup a pointer in this table. The pointer from the table
> would then be used to lookup the actual value that's
> assigned to the DTE value (located in the second table).
I see what you mean, if you use fixed length you don't need a pointer table because you can get the offset from the table by multiplying the control byte. (Sorry if I say it in a confusing way but that is just how I think).
> Each value in the second table would be ended with some kind
> of control byte so that you could tell when it ended.
Would that really by necessary? Couldn't you just find where it ends by using the pointer table? It would save space in the long run.
Right now I'm having problems finding any info on assembly for the GBA any idea where I could find that?
Ugly Joe
New member
> I see what you mean, if you use fixed length you don't need
> a pointer table because you can get the offset from the
> table by multiplying the control byte. (Sorry if I say it in
> a confusing way but that is just how I think).
Exactly.
> Would that really by necessary? Couldn't you just find where
> it ends by using the pointer table? It would save space in
> the long run.
Yeah, that would save you space in the second table, but I think would also add a bit more code to your hack. Like I said, there's many different ways of doing it.
> Right now I'm having problems finding any info on assembly
> for the GBA any idea where I could find that?
I'm not big on GBA stuff, but I think you can find some stuff like that at http://gbadev.org/gbadev</a>.
> a pointer table because you can get the offset from the
> table by multiplying the control byte. (Sorry if I say it in
> a confusing way but that is just how I think).
Exactly.
> Would that really by necessary? Couldn't you just find where
> it ends by using the pointer table? It would save space in
> the long run.
Yeah, that would save you space in the second table, but I think would also add a bit more code to your hack. Like I said, there's many different ways of doing it.
> Right now I'm having problems finding any info on assembly
> for the GBA any idea where I could find that?
I'm not big on GBA stuff, but I think you can find some stuff like that at http://gbadev.org/gbadev</a>.
> I'm not big on GBA stuff, but I think you can find some
> stuff like that at gbadev.
Thanks tons the site looks perfect. I have one stupid question I haven't really downloaded stuff off scourgeforge before. Here's the thing I want to download: http://sourceforge.net/project/showfiles.php?group_id=67315&package_id=65702&release_id=139837
My question is: Do I need to download all of those or just one?
> stuff like that at gbadev.
Thanks tons the site looks perfect. I have one stupid question I haven't really downloaded stuff off scourgeforge before. Here's the thing I want to download: http://sourceforge.net/project/showfiles.php?group_id=67315&package_id=65702&release_id=139837
My question is: Do I need to download all of those or just one?
Ugly Joe
New member
> My question is: Do I need to download all of those or just
> one?
In that case, I believe you'll need all of them.
However, DevKit Advance, I think, is for making homebrew GBA programs. I don't know how well it will work for making something that's going to be placed into an existing compiled program.
> one?
In that case, I believe you'll need all of them.
However, DevKit Advance, I think, is for making homebrew GBA programs. I don't know how well it will work for making something that's going to be placed into an existing compiled program.
> However, DevKit Advance, I think, is for making homebrew GBA
> programs. I don't know how well it will work for making
> something that's going to be placed into an existing
> compiled program.
You're probably right. Do you think I even need an assembler? Couldn't I just look at the opcodes and type them in the hex editor? Here's my progress so far: for the section I'm currently translating I have typed everything that it is going to be changed to and I wrote a program in z80 implementing DTE so I know I can code one in another assembly language (z80 is pretty restricting compared to other assembly languages from what I have seen) and I am currently writing a program in VB that will tell me what pairs to use. I'll post when I get it working in case other people are interested in GBA translations.
> programs. I don't know how well it will work for making
> something that's going to be placed into an existing
> compiled program.
You're probably right. Do you think I even need an assembler? Couldn't I just look at the opcodes and type them in the hex editor? Here's my progress so far: for the section I'm currently translating I have typed everything that it is going to be changed to and I wrote a program in z80 implementing DTE so I know I can code one in another assembly language (z80 is pretty restricting compared to other assembly languages from what I have seen) and I am currently writing a program in VB that will tell me what pairs to use. I'll post when I get it working in case other people are interested in GBA translations.
Ok I got some info on assembly on the GBA and I can't find the code in the game that displays the text. I'm using VBA and the Disassembler tool that it has. During pretty much the whole game it just loops between three different instructions so I'm not sure how to find the code. Also I have another question: the game I'm hacking has several fonts (one small one and 3 large ones to display names of the place your in, etc.). Do you think I will need to make 4 different DTE hacks?
I have been trying to adapt Kingmike's tutorial for the GBA and I got up to the part where you find the pointer to the text in RAM. It isn't as complicated for the GBA since there aren't banks but the problem is I can't just search for the instruction that loads from there because I don't know which one it is. There are lots of instructions it could be in the asm for GBA but from looking through the code it looks like usually the load from a register and add to it to get the adresses to load and keep the offset of something like the part in RAM where all the text variables or something like that are in a single register. The problem I'm having is I have no way of knowing what is in a certain register at the time it is printing the text because when I run the dissassembler in VBA it is just looping through 3 instructions throughout the entire game. I changed these and it didn't seem to affect gameplay at all.