In cases with lots of text and pictures when formatting is important I've always preferred PDFs. Though, those can be a little more time-consuming to make. And then there's the size thing.

What I meant before when I was being dragged off line was that there should probably be a collective document on Final Fantasy of things that TONS of first-time hackers ask. The locations for the opening, the bridge, the end, how to make the character names 5 slots wide, how to edit this or that. Something less complete as FFBytes, but something that the first-time hacker can use without going "Duh-hur wha?"

Paint Shop Pro is EXCELLENT, you can't go wrong with guys from IL&M, you might want to update your version if possible, you can get a free trial of Paint Shop Pro XI but I guess that doesn't help you in the long run.

Last time I looked, what this site needed was a doc covering how you swap pallettes used. Not change the pallette set, but what pallette is assigned to what sprites. I remember there was one, and the method worked good for Dragon Warrior, but not for any other games I tried it on.

Okay. I'm going to violate a forum rule (maybe since I'm a moderator I'll issue myself a warning) and revive this year old thread.

A post by Rai in the screenshots thread got me thinking that maybe what we need is some getting started tips. People have gotten themselves into the idea that you can't do an decent translation without learning assembly or something. There's a lot of little tricks that haven't been really written down that would be great for getting people started.

So it's got me thinking. What is the absolute minimum you need to understand to do a decent translation hack. So you've got tables, pointers, graphics (fonts). The three pillars. And once you've got them down pat, there's some tips and tricks you can do to make things better. Font tricks like dual tile (erroneously disparaged with terms like "squishy tile"), simple small asm hacks (for example window resizing or in some cases font resizing).

The very idea of collecting together tips and tricks about "simple" things that can make a hack look a bit better may be very beneficial. Beyond the advantage of getting better looking results, it may also help people think about the engine behind the data differently, perhaps getting people to be better hackers.

Neil, if you could write a document explaining how to locate the pointers, relocate, expand, and successfully insert the text back into that Fire Emblem game Rai was working on without using a debugger or knowing any assembly, I'd be seriously impressed. Not only would I be impressed, but it would probably be an invaluable resource. I'm serious. I can't say I could come up with a way myself.


I believe there are certainly games that you cannot do a translation AT ALL for without assembly. Games with compressed data come to mind. Though compression aside, I've seen several things that you probably wouldn't be able to do without assembly that were required just to do the translation and not really related to quality. It depends on what the game is doing and how it's structured.

I think people get themselves into the assembly idea because:

1. Assembly/Reverse engineering works 100% of the time if you're skilled enough.
2. Non assembly techniques work a fraction of the time and aren't useful beyond some games.

So... there's really no negatives to going in the assembly direction other than complexity. The non assembly methods aren't going to work in all instances.

It also needs to be made perfectly clear that every game can be totally different and your non assembly techniques will likely fail on many other games. At least if you're aware of that, you'll know to try something different rather than think the method is supposed to work and ask why it doesn't.

Hell, even a full tutorial on hacking Game X from start to finish may not be all that useful. It may even generate even more forum requests because people saw method X was used in that tutorial, but it doesn't work in their game. You know my views. Conceptual documents are key. People get way too focused on specifics that don't work beyond a narrow range and don't understand why. They dismiss documents for platform X thinking they'll be no help. etc. etc. I've been there and explained that before.

I'd like to see a document giving the breakdown of common PS2 2D formats (like Tim2) and also info on adding subtitles to common PS1(STR) or PS2 (PSS)video files.  I wasn't able to find significant info on either of these topics anywhere.

To offer my novice opinion about Neil and Nightcrawler discussion: I think you both have a valid point but I definitely think Neil’s idea has merit. If it included a decent section on how to choose an apropriate game to begin with, a 'non-assembly' beginner’s guide might avoid nightcrawler's mentioned pitfall. It seems like a lot of beginners try to take on a world renowned RPG installment that no one else has managed to crack in the past 20 years. If instead they were given a few pointers on how to choose a simple appropriate game they might actually succeed instead of flooding forums with unanswerable questions.

For instance, it seems to me that the PS1 is an excellent platform for a beginner to start on. Because of the room available on a CD, developers tended to be very sloppy with space and many tittles don't use compression.   Most of the time things are even divided into nice little packages like 'Dialogue.bin' or 'Movies/Opening.str' - a beginner's dream! Formats were semi standardized (TIM, STR SEQ) which makes them easy to recognize and alter. There are probably even some simple titles like fighters that could be completely translated just using a photo editor on Tim files.

Another thing to point out in a 'non-assembly' beginner's guide is that you don't have to completely translate a game to have your project be of value. I've seen some titles where just a few key menu parts were translated and it made the game infinitely more enjoyable to play.

-just my 2 cents :huh: