News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - milkmanjack

Pages: [1]
1
Newcomer's Board / Re: Game formats, game processing, and assembly?
« on: January 09, 2013, 02:21:34 pm »
Not off the top of my head... no. From the context of your post, this is probably a bit too simple for you, but this is the first document I ever read on the topic. I ended up going through the motions, being confused, and then looking up tons of info to fill in the gaps. Really let me know how little I knew about computers (I was like, 10, and thought I was the shit).

I think this might have helped me a lot, despite being simple enough. I came to the realization that save states are really just RAM dumps, so technically speaking if I know where data is in the save state I know where it is in RAM. I'm playing with some of these emulators with debug functions. I did some messing around and made some breakpoints for when it tries to access some data I could easily look at, and I've been messing around with trying to figure out how it changes it, and what operations at what point are doing it. I haven't gotten far, and I don't know what I'll get out of it, but it's something to do at least.

I'm really not sure on the ROM corruption stuff. It sounds like I'd have to atleast have an idea of where stuff is. Just changing random bits of the ROM seems like it wouldn't be very effective.

Thanks for all of the input, though, everyone. Really appreciate it.

2
Newcomer's Board / Re: Game formats, game processing, and assembly?
« on: December 30, 2012, 01:25:03 pm »
The thing is that nearly every game does this differently. It depends completely on the game engine used. While some engines are used for multiple games there still are a lot of them out there. Expect a new one if the game isn't a level pack sequel. And even then there is the likelihood that some things have changed.

The GBA has a bios with a few chunks of built in code. That's all that you are guaranteed will remain the same. It may not be used in the game, but it will at least remain as it is.

I guess I kinda suspected this to start with, but I wasn't really sure, since I have no experience or expertise on the subject. After making this thread, I opened up some GBA and SNES games and tried to just find information that I usually can find, like dialogue and such. After trying for like an hour to locate the dialogue in any of the Final Fantasy Advanced (GBA) titles, I had no luck. I tried every tool at my disposal. I tried relative searches, and I tried comparing savefiles to find name locations, and then using those bytes for the tables. I couldn't map any of the information I found to any dialogue on the game ROM, so I have to assume these particular games compress their text or use some weird format (maybe each character is represented by two bytes or something, for a wider range of characters? tried to search for this, but nothing).

I only tried one SNES title, but after looking on the web for the title I found a website the extensively explained the compression algorithm for the game's resources, which he I guess found in the code for the game in assembly. Now, this is beyond me, so I didn't do much reading on it. I just knew I had no idea how he found out, or where to apply this decompression (should it apply to the entire game, or are there specific blocks of data that should be decompressed?).

I suppose my big issue is... how do people figure out what data goes where, and why? I mean, to me, all I see is a big block of numbers. I don't know what I'm looking for. If it wasn't for the existence of relative search, I probably wouldn't be able to find dialogue in a game at all, as evidenced by the problems I had with the SNES and GBA games. I can even get further than this in PSX games, like Tales of Destiny which has raw ASCII (or ASCII-style ordered) text, but with compression (which I managed to figure out with a post on here).

So how do these people know what data is where?

I'd say the best way to learn is to read a guide that walks you through a basic hack, and GOOGLE EVERYTHING you don't understand.

Do you have any suggestions on this matter? The only guides I've found relate to graphics and text hacking, which are very general and aren't very specific. Graphics hacking, I've only found people suggesting using editor X, and for text hacking, people just suggest a hex editor like windhex and relative searches.

Is there something more in-depth than that around, and can you throw me a link?

What henke37 said, that said although I am in no hurry to cast aside my meagre assembly and assembly driven debugging skills a proper understanding of the things you listed and some of the higher level techniques employed there can do an awful lot of damage. If you have truly never looked at some of the debug functions of an emulator though there are some basic but very powerful techniques that do well, I tend to find most people get introduced to them in passing when learning about the sorts of things you discuss though even if they do not realise it.

I haven't really found anything about emulator debug functions.  I haven't done a lot of real research on the subject since I feel kinda lost on it, but I guess I could do some searching around.

3
Newcomer's Board / Game formats, game processing, and assembly?
« on: December 25, 2012, 05:24:16 pm »
I made a few posts some months ago about tables, string pointers, font icons and text compression. At the time, I was really just focusing what I could do with what I had, without having to figure out the inner details of the game or the platform. Now I'm trying to get back into it, but I'm trying to take a better route.

I think I read somewhere, or was advised at some point, that learning about the GBA's processor would let me know more about the inner workings of GBA ROMs, like where it stores data and why, and in what format, and so on. Another thing I've thought about is how the game itself is reading the data. I've seen people refer to reading debug output for the actual activities the GBA (or any platform) is doing as the game is playing; things like reading data from the game ROM and then using it for stuff. If I could get information like that, I imagine I could save a lot of time and effort figuring out, for example, what it looks like when the game is writing text to a dialogue box, or animating a sprite, so on.

So if anyone is knowledgeable about things like that (any platform), I'd love to get some responses or some private messages. I know the question is kind of vague, but I'm trying to express myself as best as I can about something I know nothing about.

I'm also trying to find a good book on assembly, because there seem to be basically no kind of easily accessible resources for assembly on the web. I know it's different between processors, but I know there are basic features they all share, like putting data at some location in memory, adding and subtracting, dividing and multiplying, bit operations, and stuff like that.

Thanks a lot.  :)

4
So just to be sure I'm understanding...

If we start compressing the string "I got a sword at the sword market," you'd get something like:

Code: [Select]
I got a [FF]sword at[F8] the [0095][FF] market
                     ^

Read the next 5 bytes [F8 = 11111000], then read the next 12 bits to get the location in the past 4096 bytes to look, and read the next 4 bits to determine how many bytes to read. In this case, start at byte 9 (I assume that's how it's formatted), then read the 5 bytes at that location.

Is that right?

5
What do you mean when you say it describes it? I understand how a 1 bit indicates that the next byte isn't compressed, but what exactly does it mean when it's 0?

Code: [Select]
4BE:3300h: 4E 65 75 65 73 74 61 64 FF 74 20 41 72 65 6E 61  Neuestadÿt Arena
4BE:3310h: 00 FF 43 68 61 6C 6C 65 6E 67 FF 65 72 73 27 20  .ÿChallengÿers' 
4BE:3320h: 57 61 69 FF 74 69 6E 67 20 52 6F 6F FF 6D 00 0C  Waiÿting Rooÿm..
4BE:3330h: 54 68 65 72 65 FB 20 61 55 A0 74 6F 6F 20 6D FF  Thereû aU too mÿ
4BE:3340h: 61 6E 79 20 6D 65 6D 62 FE 3F A0 20 69 6E 20 74  any membþ?  in t
4BE:3350h: 68 65 FF 20 70 61 72 74 79 2E 0A FF 57 68 6F 20  heÿ party..ÿWho 
4BE:3360h: 77 69 6C 6C 9F 20 6C 65 61 76 5A A0 71 A5 3F FF  willŸ leavZ q¥?ÿ

This seems to be the beginning of the string, and it is consistent for the most part, but I have no idea how to parse it after awhile...

Just not sure what to do with the data.

6
So recently I started messing with editing dialogue for Playstation 1 games, and I ran into an interesting problem I can't seem to really understand. I've tried quite a few games, and the problem is pretty much always there, so I assume it has to do with how the Playstation stores its data.

Basically, whenever I find some dialogue or text meant to be loaded in a file, there is always, ALWAYS, some totally unrelated set of bytes every few entries within the file. Sometimes predictable, sometimes not.

Here's an example of an English game, with the dialogue in ASCII.
Code: [Select]
Dymÿlos "Youÿ're not ÿusing yoÿur brainý,
It seems to be putting FF every 8 bytes or so within the dialogue, in this particular scenario, but then most of the dialogue I can even recognize as dialogue looks like this:

Code: [Select]
There a9・too many members in the party. Who will マleav>・
This is obviously a message indicating that there are too many members in the party, and asking you who will leave. Then you get things that seem like dialogue, and are garbled beyond legibility.

Code: [Select]
"I'm going home.  If you need my help・ c」・fiウPyrigl."汝gtS 挺約ee hangin';ouニqujメ・ィⅵh橇,゚ justセn?d
I have a similar problem with FF7 in Japanese. I've already mapped out all the kana characters, so I can grab bits of a conversation, but it seems to kind of switch modes to print kanji. So if a kanji is near, I stop being able to read the dialogue. It also is injecting those random bytes around it, as well.

Code: [Select]
ビッグス.「さ[FF]すが、ソルジャー[kanji coming up...]ミB)[kanji passed]でもよ、[kanji coming up].M.ゅ[FF][kanji passed](しんら)ゲルー[FF]プ 【アバランチ】[the rest of the dialogue is cut short, or just not in a readable form]
I really am not sure of where to go from here. I tried reading directly from the data files in the disks, and the results are the same. The text seems to be compressed or something. I've tried doing searches for related stuff, but I can't seem to find the right way to phrase it.

7
Newcomer's Board / Re: New to Hacking -- Script and Graphic Editing?
« on: February 25, 2012, 07:39:31 am »
Just to verify I'm understanding the concepts...
(since there seems to be more information on it, I'm using the English version of Pokemon Red for this test)

Locate the location in memory of the text. In this case, we'll use a string located at 0x8A425.
To get the 2 byte pointer used to refer to this string, address mod 0x4000, giving us 0x2425.
Since the address of the memory is 0x8A425, it is located beyond the first bank. Add 0x4000 to get 0x6425.
To get the bank byte that refers to the bank 0x8A425 is stored in, divide by 0x4000, giving us 22.
This means that the 3 byte pointer to this string will be 0x226425.

Finally, convert to little endian.

2 byte pointer: 0x2564
3 byte pointer: 0x256422

Test: found the 3 byte pointer in memory at 0x6254. got the location of another string in memory using this method, and replaced 3 byte pointer with the reference to that string (0x0D6422).

Result: Totally worked.

High five. Now I guess I just need to find out where the table begins and ends? Is there a way to do this? And will all of the pointers in this block be 3 byte pointers?


You might want to check your table against these topics:
http://hax.iimarck.us/topic/274/
http://hax.iimarck.us/topic/160/

Thanks! This should help to get the more obscure characters, and the descriptions for the ending bytes seem to be a bit more accurate. Updated mine accordingly.

Also, did you know that for the string you have selected in that image, the string actually starts on the byte before (on the 00), not on that byte?

I assumed this was the case. That's why all the string start with x in my Cartographer generated script. That's my null character.

February 25, 2012, 01:04:00 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I seem to be having some problems with the Japanese version of Pokemon. I did the same process as with the English version, and the results are pretty different.

The intro dialogue starts at 0x603C. This should mean a pointer to this data should be stored as 3C60[01], according to this method. I managed to find it at 0x5F4A, though instead of the bank byte [01], I found [CD]. To ensure this was in fact a pointer to my dialogue, I found some other dialogue in the same area in memory and changed the pointer to refer to it. This worked. However, when I tried to change it to dialogue stored in further parts of memory, it simply didn't work. And I assume this is because of that third byte. Either the CD is a reference to that bank in particular, or just a reference to "this block."

It seems all of the pointers in the English version are in the exact format as discussed earlier in this thread. I was even able to define a string out in unused memory space and it worked fine.

I'll have to do some more tests.

8
Newcomer's Board / Re: New to Hacking -- Script and Graphic Editing?
« on: February 25, 2012, 01:59:37 am »
Well, for string lengths, you'd dump the entire script to a text file using Cartographer, format it for reinsertion, edit it as you saw fit, and reinsert using Atlas.

String lengths are dictated by pointers, which are address values telling the game where to look for each string. A properly-edited Atlas script will have pointer tags telling the inserter where each new string starts and where in the pointer table to write the new value.

I think the only problem with this is that I have no idea how pointers or pointer tables work. I was reading that there are blocks of data that are dedicated to storing pointers to other locations in memory, 2 bytes for data in the same block, or 3 bytes for data in other blocks (where the first byte refers to which block to look in). I really have no idea what to look for, though, or where to even begin looking.

Grabbing the raw script was easy enough though.

For name lengths...well, there's no easy way around that. You'd have to hack the game to use the same ten-letter method as the US versions, not to mention reposition on-screen text and add an extra page to the Pokédex entries.

Really, Pokémon is probably an awful choice for a first translation hacking project. It does have the advantage that you have an English script to compare with, but the amount of hacking you'd need to do makes such a project unfeasible. Though if you're dead set on translating one, FireRed might be a better choice. Since Pokémon can be traded between different language versions in the Gen 3 games, it's likely you won't have to do as much hacking (or any at all, really) to get ten-letter names.

I was afraid of that. To be honest I didn't even consider the problem of the name limits until I was writing that post...
Though if that is the case, it isn't really a huge problem for me. The main goal here is to find out all of the things necessary to edit graphics, find scripts, and edit said scripts. Once I understand the principles behind these things, I'll move onto different stuff.

9
Newcomer's Board / Re: New to Hacking -- Script and Graphic Editing?
« on: February 25, 2012, 12:11:45 am »
I recommend using Crystal Tile 2. It is the super best, easiest to use application.
You can find it in the utility section here on RHDN: http://www.romhacking.net/utilities/818/

If you use it and mosey over to offset $10B19 and use 1bpp mode, you will see the whole, uncompressed Japanese alphabet

This worked quite well. On the Japanese version, it showed the font perfectly. When I tried it on the English version just to see if it'd work, it seemed to start drawing the alphabet characters 1 pixel too low, as the top pixel of the font characters were cut off. Not a big deal, but anyway...

From your screenshot, it looks like you managed to create a complete table. That was probably hard without knowing the order of the letters? But kudos to you for doing it.

What I did was just create 2 savefiles and compare the bytes. I did this initially to find the location of the character names in the files. To start with, I named the character アイウエオ. This revealed that those bytes started at 80 and ended at 84. Then I tested characters in the K category, and saw that it started just after オ, from the bytes 85 to 59.  Then I created a generic table starting from what I knew, A-O and KA-KO, and did S, T, N, H, M, and so on relative to this data. It required a bit of time to get the rest of the characters, since they weren't as intuitively placed.

After I got the entire library of obvious characters, I opened it up and looked for the intro dialogue while running the game. From there, I just looked for patterns to determine what certain bytes did. It took me quite awhile to realize the specific functions of the "end" codes. I still am pretty sure I don't fully "get" them. I tested out the "fade out" byte, but the fade only occurred when it normally did during the intro (meaning it probably isn't a dialogue function, but the function of the game itself). I found all it did by putting it in there was end that dialogue (with a pause), and then jump to the next dialogue.

I also found out that there is a special code, represented with [50], that seems to act like a kind of reference character. For example, when it occurs in dialogue, when it gets to the byte sequence [50 14 00], it plays the Nidorino growl sound. You can play with the second byte to make it play different sounds, though certain ones make it start printing stuff beyond the dialogue box and eventually crash, or sometimes completely skip the intro dialogue, assigning specific values for your name and your rival's name. [50 01 68 CD 00] seems to be a reference to the pokemon your rival picks during the opening bit ("(Rival) received (pokemon) from Oak").

Still not entirely sure how the references work, but yeah.

To make an English font, it is as easy as just pasting in a 1bpp bitmap of your font. I literally just type out the alphabet in photoshop, copy it, and paste it directly into Crystal Tile 2, starting wherever the Japanese alphabet started (though it could be anywhere, that is just a convenient place). Be sure to save the ROM afterward.

If the katakana alphabet started with アイウエオ, then in your table, script, and WindHex you can see those letters correspond to values 30, 31, 32, 33, 34 (hypothetically). If you pasted your alphabet starting with "abcde" on top of those letters, now, those values correspond to your English letters. If you think about "7F" not referring to ま, but referring to the tile which stores some graphical data that happens to look like ま, it should be easier to understand. If you put a heart image in that same box and then you run the game, all ま letters would be turned into hearts.

Yeah, I just played with it a little and replaced some characters. Ultimately, once I replace all the font characters, I'll have to retype every line of dialogue. I will probably write a program to do this for me, so I don't have to do it all in a hex editor... I hope I'm competent enough to do so.  Probably just a simple command line program.

Everyone else on this board is smarter than I am, and I'm sleepy, so I'll leave my explanation as it is. If no one has told you how to deal with pointers by the morning, I'll share what I know on that end.

I really appreciate the help, too. With the ability to edit the font, I could theoretically begin translating right now. The only problem being I don't know how feasible it is to translate with the current string lengths. Converting ”グリーンは オーキドから ヒトカゲを もらった!” to "Green received Charmander from Oak!" would be impossible, for example. Even if I just reduce it to "Green received Charmander!", it's still too long! Not to mention the maximum name length is 5 characters! huhuhuhuuuuuu......  :-\

10
Newcomer's Board / New to Hacking -- Script and Graphic Editing?
« on: February 24, 2012, 06:22:02 pm »
I've recently decided to take up a bit of rom hacking, just for fun. My main goal is to eventually have the skills necessary to translate games and such. My first attempt to do this, I decided, would be with Pokemon Red for Gameboy, for no particular reason other than I really enjoy the game, and it is quite easy to read.



The first thing I decided to do was to find out how to locate/view the scripts. I read about tables, and about some techniques to determine what bytes represent what "font entity." What I did was made two save files, made the characters names in reverse, and then did a comparison. After looking through the places with a 5 byte difference, I found where character names are stored, and the range that is used.

This is pretty much where I'm at right now. My next goal is to figure out how to A) edit the in-game font, so that I may change the language the game draws in (to English), and B) edit the script in ways that allow me to add extra text.

For A, I have tried a few graphic editor tools. Almost all of them result in the output being garbled except in a few places. After looking around, this seems to be because the graphics are compressed. Unfortunately, I have no idea how to continue at this point...  I've tried a few things, but I can't seem to find what I need.

For B, from what I have read in the past, changing script sizes can be a problem. Due to the way pointers are, changing lengths of one thing require you to move pointers of other things. One thing I was trying to do was find references to the beginnings of dialogue in hex form, but I couldn't find anything for any of the few dialogue entries I tried.

If anyone has any useful information of resources I could use for this, I'd really appreciate it. This is something I'm kind of really interested in doing, but I have very little experience with handling files like this... as in, none.

Thanks!

Pages: [1]