@Sp33der what psycoblaster was getting at is that roms can use all manner of methods to store text. I am assuming you have a grasp of the principles behind text encoding (table making) and pointers.

In general assuming the text is not in the binary then it comes as files in the file system, usually as distinct files but occasionally as part of a monster file (see theli's recent work on Culdcept DS http://gbatemp.net/index.php?showtopic=109841 or have a go with the first tony hawks game or the earlier phoenix wright games).

Still the general arrangement is pointers (which are usually in the same file but not always) followed by text and this is where it gets complex as you then have formatting and wildcards to deal with.
Pointers can be used to end sections and lines or the line ending characters can be in the text itself and to make matters more confusing this can often be a single byte in among a 16 bit character set which can mess up basic viewers (it is prominent in shiftJIS based games). A note on formatting though, games can sometimes wrap lines and other times you need to do it by hand.
Pointers need not be end to end either, many times other useful and not so useful pieces of data find their way into the pointer section (many games use 4byte or more entries when one byte will do), I discuss the basic pointer techniques elsewhere so I will leave that for now.

Wildcards (think "please pay [amount] for a room for the night" or "you have [money value] dollars") can be anything from square bracketed human readable terms (final fantasy 3 has a nice example if I recall correctly) to single bytes and can even be determined by things in the pointer sections. New Super Mario Brothers has some good examples.

General formatting, compared to earlier consoles the DS is quite powerful and so many games can have things that makes text flash, appear in a different colour, wobble on the screen..... Some games have it in the binary while others have it in the game much like wildcards.

All this is why we suggest manual dumping or a custom text dumper as the dumpers are either too low end (some of the first ones are little more than glorified file trimmers), too specific (several text dumpers are game specific later modded into a more general form) or as complex as programming a new one (none of these exist in any real form as far as I am aware).
You also have the option of serving up your text dump to the translator in a complex form (leaving the formatting as in the game for example). Text usually compresses fairly well too so be forewarned that you will be dealing with that too.

i is the current counter, (my loop reads 1 byte at a time)
and the textLength is part of the file (requires a little bit of reverse engineering)

I create Hashtables for table files.
(Character map as the key and character as the value; other way around for converting text back into binary)
You always need to be aware that the text can be both double and single byte, so I read one byte at a time.
Convert the value to a hex string, and then look for a match in the Hashtable.
If there is a match, then I deal it as a single byte character.
If there isn't, then I also read the next byte, and put the 2 hex strings together, and get the double byte character.

It is really easy once you understand the basics of text files.

Usually, in the most common formats of text files, there are only few values when reverse engineered -
Count (number of lines)

For each line,
Pointer (Where the text is located in the file)
Text length (The length of the text)
Line (The actual string)

There can also be control codes for color, font, location, speaker, top/bottom screen, etc, which might need extra testing to figure out.

i is the current counter, (my loop reads 1 byte at a time)
and the textLength is part of the file (requires a little bit of reverse engineering)

I create Hashtables for table files.
(Character map as the key and character as the value; other way around for converting text back into binary)
You always need to be aware that the text can be both double and single byte, so I read one byte at a time.
Convert the value to a hex string, and then look for a match in the Hashtable.
If there is a match, then I deal it as a single byte character.
If there isn't, then I also read the next byte, and put the 2 hex strings together, and get the double byte character.

It is really easy once you understand the basics of text files.

Usually, in the most common formats of text files, there are only few values when reverse engineered -
Count (number of lines)

For each line,
Pointer (Where the text is located in the file)
Text length (The length of the text)
Line (The actual string)

There can also be control codes for color, font, location, speaker, top/bottom screen, etc, which might need extra testing to figure out.

Click to expand...

Ahhhhhhhhhhhhhhhhh, thanks alot man, i understand most of it, but i know shit of C#(it is C# right?) so i don't understand some lines , thanks again anyways

Actually if you're looking to write a custom inserter, looking at the source to an existing one would probably be the fastest way to get started.

Click to expand...

Oops I just copied and pasted my code, so I didn't catch that
Actually, I kept your Util class and added my own stuff for dealing with files, such as my custom table code, text file -> string array, etc, because I thought it was worth keeping what was there

Actually if you're looking to write a custom inserter, looking at the source to an existing one would probably be the fastest way to get started.

Click to expand...

Oops I just copied and pasted my code, so I didn't catch that
Actually, I kept your Util class and added my own stuff for dealing with files, such as my custom table code, text file -> string array, etc, because I thought it was worth keeping what was there

List is a generic list class C#.
Similar to how you can set the types of the contents in an ArrayList in the latest version of JAVA, I set the content type of the List class as String.
so List textDump is similar to String[] textDump
However, a List, similar to an ArrayList, expands and contracts its size, rather than having a fixed size such as an ordinary array.

umm so which ones better/ easier to use C++ or C#? Because I don't want to go and learn the harder version when they're both the same.

Click to expand...

That depends on what you are going to do.
There is NO harder version. It just depends on what you want to do and how you want to do it.
Just for ROMhacking purposes, both can be used, as they are both similar is style.
Because C++ was here for a longer time, C++ should have a larger library compared to C#, but for everything basic, C# is good enough.
So it just depends on what you want to do. If you learn one, then it isn't hard to learn the other, as they are both very similar.