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

Author Topic: Rom Translating?  (Read 388 times)

patrickanonymous

  • Newbie
  • *
  • Posts: 1
    • View Profile
Rom Translating?
« on: October 24, 2020, 03:31:35 pm »
Hey all,
I'm trying to get into ROM translation, but I can only find 1 tutorial on it and it was extremely confusing. Can anyone link any good tutorials or provide any tips on how to get started? Also what is the best hex encoding(Unicode, ASCII etc)

FAST6191

  • Hero Member
  • *****
  • Posts: 3023
    • View Profile
Re: Rom Translating?
« Reply #1 on: October 25, 2020, 04:59:43 pm »
The best encoding is the one the game uses, be it the original one from the devs or a custom one because you changed it when playing hacker.

What tutorial was it?

The getting started link for this site usually sets most people down the right path here
http://www.romhacking.net/start/

I have one focusing more on the GBA and DS, though will do for the general case as well.
http://www.romhacking.net/forum/index.php/topic,14708.0.html


To go even more short there are four things you will likely be concerned with here

1) Text encodings

2) Pointers

3) Graphics

4) Any markup used in the text.


1) While most PCs and the like use one of a list of known encodings most old games, and still nothing unusual for something released yesterday, will be out and out custom encoding.
I usually describe encodings along the lines of the basic "code" we all probably made as kids where 01 = A, 02= B and so on (technically speaking is a type of Caeser cipher). Except here the numbers are in hexadecimal because computers and there need not be a thread of logic that unites ordering. There often is a thread of logic but that is on you as the hacker to figure out, or just brute force it until you get the right one.
This list of data will be collated into a big text file that in  called a table
If you are bored here is a proposed standard http://transcorp.romhacking.net/scratchpad/Table%20File%20Format.txt but most will just use the ones that work with their hex editor or text tripping tool (atlas and cartographer being the two tools most around here will use if they are not going straight custom, though Kruptar 7 and Oriton are rising in popularity).
Typically western games will use 8 bit encodings (saves space) whereas Japanese will use 16 bit (8 bit =256 max characters, Japanese has thousands) but there are many exceptions, and also there is some really rare stuff that will opt for 24 bits.

2) Pointers. Games don't want to have to calculate when the end of a section is, possibly even end of a line in some games. Fixed length sections also don't work (though many menus do opt for it). To that end there are long lists of where such things are located. I usually liken them to a contents page in a book. Much like in a book if you add or remove data then turning the number of pages it says will make things be out of line. The would be text hacker soon then gets to figure out pointers to sort this as you will not get far trying to match lengths of text. There are various types of pointers. Some will be simple locations within a file* (or memory or the ROM), some will be relative (take the current location and add this value, now you have the result) and offset (this number but we start counting at the start of the text rather than the start of the file, you can have relative offset but I would struggle to provide examples of it in the wild).

*games that came on floppy disc, optical disc, or are the DS and newer will tend to break things down into individual files. Older stuff will tend to pack it all into the ROM with no real ability to explode a ROM into separate files.

3) Graphics then. Two main areas with that being font (Japanese games do not always have Roman characters, and you might want others anyway).
Games, especially simpler games, might not bother with text and instead kick things to graphics instead. This is also good for decorative things (be it looking fancy or markings on shops, inns and whatever else in games). A tile editor is what most use to play around here. I like crystaltile2 myself (it is an all in one program but very good still for graphics), though tiledggd and tiled2002 are also things in my arsenal.

4) Games, especially newer ones, might want something fun done with the text to note what character is speaking, how much an item costs here, how many of a given thing a player has, make things bold, make things shake or something to emphasise it and so on. This can be done in the text, just before a given line starts, in the pointers, in somewhere else. If you have a basic idea of HTML then similar ideas, though again need not be in with the text itself like HTML.


In with all this there are things to make life harder like compression, things being put in the binary (the computer does not care so lazy programmers will wedge things in with instructions on running the game and not keep it separate, as you can't exactly phone them up and tell them to code better you as the would be ROM hacker gets to deal with it), and just because one aspect of a game uses one style does not mean the other part of it will (some NES games even change things as they are decoding, or from one frame to the next).