1.6 Abstraction

Certainly a topic worthy of a document all to itself the main idea here is related to the jargon earlier. Coming at the cost of not being immediately accessible to all (or in this case the computer in question) you build a method by which to interpret something into a format understandable by a target, in this case usually the console in question which translates it to a usable format. Such a move obviously has speed penalties, the bonus however is that you can use a simpler method to store, deal with and hopefully change your chosen item as necessary.

Programming languages are all about this as they all attempt to move away from a user feeding the computer a string of 1s and 0s. A nice example might be to compare the GBA and DS for if you recall the GBA lumps everything into one file where the DS can explode a ROM into a series of other files. Now if you want to add a section of code to the GBA you either change all references to everything after the section you are increasing in size accordingly (a very tedious process that nobody ever does) or add to the end of the ROM (or some other blank space). On the DS your ROM rebuilding tool simply adds the extra to the locations of the subsequent files (and other sizes as necessary) and as the files are not usually tied to each other as whole (obviously files can work together on occasion) nothing is troubled. However when compared to the GBA it does mean the DS will have to do an extra step when it comes to running the ROM to figure out where to point the read command. Much like a unified theory of physics there exists a theoretical but perfect level of abstraction that you could feed an initial value into and have it run accordingly but much like physics you occasionally want to get some actual work done so you cut it off and possibly simplify/restrict things so as to set about getting that something done.

Related to this is that not all the data you see in a ROM will be used in it. For instance any file names contained within subfiles or occasionally even the files themselves might be completely irrelevant, as might be some of the pointers/size values. Generally though it pays to know and understand what each value might mean and account for it as you edit the files unless you can demonstrably prove it does not matter.

This also applies in reverse with some developers choosing to hardcode values somewhere despite not having to or it even being all that good from a programming quality standpoint (as a ROM hacker you might well have to fix several bugs introduced in such a manner); remember that game programmers are people too and are no strangers to the hack something together and knock off for lunch routine.

If a rule of thumb has to be made it would be understanding the level just above the thing you are trying to do will tend to be beneficial and such a logic underpins a lot of the content of this document.