I find the way you tackle these topics both interesting and fresh, and fairly naive too.
Sounds like a lot of work. The reason I somewhat dislike editing images that function as menus and the like is that no matter what I do the end result will never look as good as the original game tile/texture.
It's frankly another facet of rom hacking where there is need of yet another skill set... i guess that just means I'm going to have to learn. 
Yes, graphics editing can be a field of expertise in and by itself. If you think about the way game developers staff their teams, the graphics experts are often numerous, specialized and skilled, these days. It's an important part of what makes a game.
There is of course not "one answer to rule them all" (games). There are many ways to approach graphics editing for translation. But I believe that the "overall plan" is indeed what was described, or almost:
- Identify and extract graphics with textual parts that need editing. The extraction is often game-specific, all the more for older platforms.
- Choose if you want to go for a completely different graphical style (vs keep the existing one). Bear in mind that, while doing your own thing is likely to yield coherent looks, it may mean you need to edit graphics that don't contain text, for coherence's sake.
- Choose a graphics editor for the next steps. A lot of people liked Photoshop until it became cloud-based. Gimp is a good choice too, as it is free, but a lot of people need time to get used to its user interface.
- If you want to edit with existing style, then...
- Import the existing graphics as the bottommost layer.
- Create a layer on top to "delete" the text. Which actually means you paint the background on top of the old text, guessing what the pixels were. For this step, I recommend looking around the picture for similar areas. It is often best to copy paste from other areas, and to randomize a bit the pixels. (Yep, lots of manual pixel-by-pixel steps here, although people may know good techniques they could share here.)
- Add a layer with the new text. (This way, it is easier to change if you change translations... which happens often for chapter titles and such.)
BTW, i learned today how to implement a command, so to speak in the cheat engine debugger, to change a game's font to 8 pixels instead of 16! now I'm trying to do the same on a psp game and the referenced functions are all mostly the same, and in fact they even use the same GDI32 but for whatever reason i ain't getting any joy.
You do understand there is not one way to do it for all games, there, don't you? That's the bane of RH: lots of things are done uniquely per game, which means you have to understand how these things are done for each game. Sometimes you could be lucky. The concept seems universal, but the implementation is (generally) not.
Anyway i'll stop now since this thread isn't about this stuff. So yeah, a small section on basic step-by-step editing of common images, like rpg menus, how to do it / what to use / etc, and how to re-insert them on a per-console basis. That'd be sweet.
Again, how to reinsert is pretty much unique and specific to each game. Well, yuo can find some common formats (such as GIM for PSP) but there often are non-standard ones. (Supposedly, new platforms are supposed to help with this, since their system libraries include a lot of graphics-handling and text-handling routines. I'm not sure which generation of console really offers this (I'd bet NDS, PS3), so I'll let Fast and other better-knowing people explain it.
also it'd be amazing if you included as well in that section a detailed breakdown of the many things you can do with a game's font image once you've extracted it, all the way from stuff like shaving off the rough edges, so to speak, off each letter to stuff like replacing fonts and even maybe you could include a section on making your OWN fonts to serve a game's needs best and how to do it, ttf to per-console formats and the like and how to make it work.
Font edition and creation is an art by itself. I'm not sure I understand what you're expecting here. I guess there should be websites about this with artistic guidelines?
EDIT: oh, you should also make sure to include a detailed section on how to use debuggers, what they can do and what they are for and what you can accomplish with them and you CANNOT accomplish with them; debugging is quickly becoming one of the most important facets of rom hacking and almost no one knows how to use a debugger, myself included.
I guess that by "is quickly becoming", you mean that, on your learning path, you are bumping time and time again into suggestions that using a debugger could help with many aspects of translating a game?
We've had this request quite a few times and the thing is - you have to learn programming in order to learn debugging. (At least that's what I feel.) By learning how a program you write translates into assembly,and how a debugger interacts with assembly instructions, you can learn what a debugger can do. It's like trying to explain assembly. You can write books about it, but the fastest way for you to learn it and understand it, really, deeply, is through first-hand experience. Is it slow? Yes, it is. Is it worth it? Yes, most definitely. Just like hex editing is a raw tool that allows anything (but you want to complement it with other, faster,higher-level tools), you can also reverse-engineer most things with a debugger (but it usually takes a lot of time even for small pieces of code, so you want to favor other techniques and approaches where you can).
I'm guessing you'll answer I'm not helping. Yet, from my perspective,I'm actually proposing paths forward for you,rather than just saying "it's not possible to do a one-match-them-all method and tool and guide".
and you know? also a section on what tools are needed for what task, more specifically concentrating on whether you should use a rom hacking oriented hex editor or whether perhaps what you need to do at that moment could be better served with notepad++ and using its powerful macros and ability to set automatic line breaks. that's just a specific example but it's stuff that comes up. most people don't even know about macros for text/script editing.
Good luck with that. It's a full life's worth of work.
also, i just thought... you really need a section all about tables and the crazy stuff you can do with them. and even more so what you can do with two tables at once. a lot of people don't know about DTE's and how you can stuff a table with them.
I agree tables would need a little revisiting.
DTE's are not multiple tables, for the record. They are about having several letters encoded as a single symbol. (Like representing "an" as a single byte, to spare 1 byte of space in every place they occur.)
Poll
Topic: What utility/document project should I work on? (Read 7513 times)