All the text is dumped for this one game that I'm working on, and it's to the point where everything can be translated. But the big problem is that the game has no English font and I don't believe with my small amount of ASM knowledge I can implement one. So basically you put in English text and you get scrambled crap. So I need to figure out a way to implement an English font, but I don't know ASM. The only other choice is to use two byte Japanese English which is takes up way too much space. I need to figure out a way to add an English font. Seriously though, I can't figure out this ASM stuff.

I know the essentials, but I don't know have the knowledge. I'm just trying to make so that if I type uncompressed English is in a hex editor, it displays like that in game. In this game you can only type Japanese characters, and Japanese English characters which are two bytes. You see, an uncompressed JSIS table already has a regular English font in it, where each thing takes up one byte. However, the game lacks this font. I basically want to insert an English font.

Well I know that, it's just this stuff is so confusing. So I got a debugger okay, but now what do I do with it? How do I know where the text is? How do I know how it loads the text based on all those ASM codes? I understand what the codes mean, but I don't understand how that helps you understand what the game is doing. Even if I knew how the game loaded the code, it would not help change it so that the text is one byte. I basically have to get it so the game reads two byte English, as one byte English. But still I'm confused, how would I get it to recognize the value for the regular English letters, as opposed to the 2 byte Japanese English letters? Right now English only works if you type in those two byte Japanese English letters, you type regular English, you get garbage. Once this is done and the script is translated, all that'll be left is images to translate.

"No hack for you!"


... You need to understand the algorithms of the game. Write the ASM code down, then try to translate it into high-level code, then try to understand what is happenening - the purpose of each involved routine. Then you can alter the algorithm and re-translate it back to ASM.

Well then somewhere there's a serious issue here. When you do know what every command does (and heck, even I don't know that..that's what spreadsheets are for...), you must be able to recognize the "meaning" behind it. It's like with language. You know what words mean, but all alone by themselves they don't have a statement, something they mean. Like: know; I; where; Berlin; am; in; now; right; . You could form multiple sentences out of that, but all by themselves the words don't mean much.

Same thing with assembler. Just take this for example:


You can now sit and look at it line after line, but you need to get the whole picture instead of just each and every bit. It's part of a decompression routine here. Loads a byte, compares it to F0, if < 0 goes to the generic routine (which I only quoted partially...) if not takes the last four bit as an index in a pointer table at FBCC and jumps to that index.

Try to approach your code somehow and then you'll see what it does. In general, your debugger will have a breakpoint feature. Now, look up some offset for a string you already know and convert it to the appropriate address (and heck, that is a tough job, I still don't get addressing with SNES... ) err.. use Lunar Magic and hope it works right. Then set a breakpoint and it should break either a) when it's loading all the text into ram or b) when it's reading directly what to print to the screen. Either way, you can backtrack to your text routine and start messing with it and see how it works. And that's all there is to it as far as understanding goes.

EDIT: Suzaku, your code is broken. While doing said action, the routine is going to spill an error to brain v1.0 because there is no routine for "drinking" in there Also, bits aren't bytes...but whatever

cYa,

Tauwasser

As you said the text is already dumped, so you know where it's at in the rom. Now what you have to do is determine where it's add in the console's memory. For SNES you have LunarAddress that'll convert between the address in the rom file and the actually SNES address. For the NES, ROM starts at $8000 and ends at $FFFF. Couple with a little mapper info, you can determine where the bank containing the text is gonna end up. An even easier method is to just find the pointer. Provided their "normal" pointers, the values of the pointers will be the address of their corresponding strings when their in ROM. Set a breakpoint for this address in your debugger and when it snaps you should be in the routine that reads the text.


(Emphasis added.)

If you don't understand how, say, LDA [$20],y (using Tauwasser's example) is able to load data from rom, then you don't really understand what the codes mean.


Stop thinking in terms of English or Japanese. The game does not care whether the text is in English, Japanese, Klingon or any other language. It knows that it's been given a value that corresponds to a tile or set of tiles. It takes the hex value, performs a little math to get the address of the corresponding tile(s), and then loads the data for the graphics.  (Pixel based systems are probably slightly different but the same logic still applies - hex value becomes an address where the corresponding graphic is.)

That's it. Language or what I had for breakfast do not matter.

Hardy har.

If anything, SF1 is a shining example of the kind of project a beginner with trouble learning ASM should avoid. I had no idea what I was getting myself into when I started: the shame of realizing I had inadvertently followed in the footsteps of my hated foes at Tokyopop and Dark Horse was a major impetus for going through all the trouble of completing it.

I was thinking more like a practice project: nothing he has to see to completion, but something to help him wrap his brain around the basics of text hacking. He could start with, say, hacking strings in The Legend of Zelda or Super Mario World...something he could readily get help with (of the step-by-step Invisiclues variety, hopefully) without getting stuck.

Any one of them, though I hear A Link To The Past uses an odd system where line breaks are "merged" with the byte for the last character in a line.