Perhaps switching books 3 and 4 would work well. Changing pointers and such isn't completely nescesary in every translation, such as with minor menu translations, and seem a bit more advanced then simply dumping and reinserting the text. Of course, most projects do require that before anything else, so perhaps not.

Except it IS possible in some cases to finger the link. Take compressed graphics for instance. Let's say, for the sake of argument and practicality, a font in an SNES game.

Staring at a string of text displayed in-game, what's the first thing you know about the font or at least the characters being displayed? They're in VRAM. Okay, what good does that do? Well, you need to have some idea how the graphics get to VRAM to being, usually DMA if the console allows it or via hardware ports. I'll go the DMA route for simplicity's sake.

Now, there's usually two methods for DMAing data: ram to vram and rom to vram. Since we're thinking it's compressed in the rom, we can rule out rom to vram for the time being, which leaves us with ram to vram. We need an easy way to scope ram: savestates!

Load up the rom in an emulator that utilizes an uncompressed savestate format (Gens or ZSNES for instance) and create a savestate with the string on-screen. I usually try to create the savestate about midways through when half of the string's been displayed if possible. Of course, if the game doesn't draw one character at a time, instead opting for drawing whole lines or even entire windows, you'll have to create the savestate with the string in its entirety on screen.

After that, open the savestate up in a graphics editor and check the areas of ram (you'll need to know how the particular emulator you're using lays savestates out). If you find the text, jackpot! From there you set a write breakpoint for that area of ram and then work backwards until you find the calling jump and you'll have found your decompression routine. This is even easier if you've located the text read routine, since you can ignore everything before the character to bedrawn is read AND you've got something you can follow through and see how the character's hex code is turned into its corresponding font tile(s). From there it's just a matter of studying the code, stepping through it in a debugger if possible or look at trace data.

It's the same principle for all compression. If you know what the end result is, find it and then work backwards using the tools at your disposal.

The above is a little rough and could use some more in depth explanation and examples, but it should get the point across. And that's just one method of doing it, without going in to any compression schemes at all., which isn't really necessary, imo. You can worry about applying a name to the scheme after you're finished back tracing and figuring out the specifics of the routine.

I think my long rant established compression was just ONE example of a case in point. This is bigger issue than just a compression. It's adding things to this document that aren't in others. An example like RedComet gave is one thing. It's a simple explanation of how to tie together various bits of knowledge into actually accomplishing something. You CAN point the finger in many cases where people get stuck. This doesn't have to be any huge document. Just some blurbs that make that bridge so people can understand how to do something with what they know.

I just answered several questions this week on the forums that exemplify this situation that are NOT about compression. I distinctly remember the SNES palette guy today. He had the skills, he just didn't know what to do with them. He need the mechanics of putting things together to figure out where to start to accomplish a task.

Another guy was the MTE guy. He knows how to read assembly. What he didn't know was how to put what he knows to use in figuring how how to accomplish his task. He really didn't know where to start there.

THAT's the kind of thing that we need around here. Get people over these hurdles that AREN'T in any documents to date really aside form straight code examples. Code examples are one thing, but EXPLANATIONS on a higher level are another. All the explanations I've made to people that I get thanked most for are for those that are slightly above a line by line code level, but put the missing links together for them on how they can utilize what they know to come up with a plan to accomplish a task.

I think if you're going to write new document today and you really want it to be helpful and useful, do something with it that hasn't been done to death already. It's evolution of our kind. Yeah, some people still don't know how to make a table even with 50 documents on it, maybe ROM hacking isn't for them. But there is a large group of up and coming people that know the basics, learn a bit of everything, but can't progress from there because something is missing.

Some of the old top dinosaur fossils are dropping out of this community now a days. Who's going to replace them? I see a lot of up and coming people at the intermediate level that could use a small kick or two to hurdle them into super stardom to be able to tackle even the most difficult of projects. But they need to get that kick of information.

If I only had the time to do this, I'd write such a thing, but all I can do is preach in the shades of MKendora in hopes that those who do have the time can take heed and evolve.

Ask yourself some questions. Think about taking on the most difficult project available for your system of liking. Some of you out there could handle any game for your platforms of interest, but I expect many of you could not. Ask yourself why that is? What would you need to know to be able to do so? Is it a lack of hardware knowledge? Is it a lack of assembly syntax? What questions have you asked since you've come to this board? Is it possible that your questions could have been answered in a document outlining how to apply some of your knowledge to certain situations? Or perhaps explaining some concepts to you to help things click or know what to look for in that 300K assembly file?

I'm guessing the answer to those last two might be 'yes'.

On a slightly unrelated, but still related note, one thing I think would be REALLY helpful would be some "case studies". As in a detailed step-by-step process of translating an entire game. Of course you could do one that you've done before, and use your work to shorten the time writing the document. Honestly, this kind of thing would REALLY help me, even though my system of choice is different than yours (actually, I'm not sure if you've done any GBA hacks.)

And Nightcrawler, since you seem to understand the conceptual parts of the hacking process so well, might I suggest that you write a document on that?

Another useful thing would be to explain how each concept can easily be applied to any similar platform.

That's another heavy hitter. "I've read read the documents, but it was for system xxxx. It won't help for system yyy". Few realize that IT DOESN'T MATTER. I guess it's a lack of understanding of the concept, but they don't realize you do almost the same thing and the same process for all similar platforms. Even the non similar platforms have only a handful of differences you need to overcome.

I can see both sides of this.

Sometimes, people just need a bit of conceptual information to figure out how to do things. Like that bit that RedComet said, that explained so much to me, and it could be used on not only fonts, but sprites, etc.

Then there's the other side. They should be smart enough to figure it out once they reach that level. Also, the big mack daddies of hacking didn't have any explanation hand-fed to them. They went and did it themselves, and that mentality should be inspiring to those of us who rather suck, but want to get better.

I don't have an opinion. I'm just saying that this issue definitely could go both ways.