+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Dragon Quest 6
Pages: 1 2 [3]
Author Topic: Dragon Quest 6  (Read 2680 times)
tomaitheous
Guest
« Reply #30 on: December 05, 2006, 06:42:38 pm »

Quote from: Rai
- How exactly will pointers help me insert more text? WILL pointers help me insert more text? If not, I don't really care for them.

Before I go on to everything else, I have to understand these things.

Here's a basic run down of pointers:

 First, I assume you know what arrays are and how they work. Most game scripts are setup as a variable length data array (a block of text). It's an array with the data element (or strings) being variable in size.

 There are two ways to access such an array.

 1) is to parsed through the array until you've reached the desired string by counting the number of string terminators along the way.

 2) is have another array with values that point into the variable length data array (I'm sure there is another name for this type array) for the starting position of the string of data. This type array is referred to as the table or pointer table.

Almost all games use the second method.

 The reason why you want to rewrite the pointers in the Table (array) is because the replacement text your trying to insert is either longer or shorter than the original text. If you re-position a pointer after a shorter than original text insert, then you gain the additional space for use with larger replacement text/strings.

 An very basic example:

 Say you have a town with 3 people.

 Old_man=0, young_kid=1, swordsman=2.

 When you talk to the swordsman, the text routine uses the value associated with him as the index for the Table array.

unsigned short table_array[2]={ 0x9000, 0x9005, 0x900C };

The value pulled from the pointer table is now the index for the script array.

Let's say the script is 0x9000-0x900F in length.

Of the original text: Old_man's text is 5 bytes lone, young_kid's is 7 bytes long, and the swordsman's is 4 bytes.

And the replacement text is: Old_man's text is 4 bytes lone, young_kid's is 3 bytes long, and the swordsman's is 8 bytes.

The first two characters replacement text strings will fit no problem, but the last one won't. So we scan the replacement text and build new pointer locations for them.

The new pointers would be: 0x9000, 0x9004,0x9007. Now the swordsman's replacement text will fit. You don't need to know ASM to do this.

 Hardcoded pointers are a different story. Unlike the above scenario, the actual pointers are attached to characters, elements, events, etc. If the script is stored in a block form(array), then you can extract it, translate it, and re-insert using an Overflow scheme. This does require ASM knowledge and writing the actual overflow routine. You can also use the overflow scheme in-conjunction with rewriting the pointers(above example) to avoid using compression schemes, but you'll probably need to expand the rom. I did this with BubbleGum Crash.

-Rich

Nightcrawler
Guest
« Reply #31 on: December 06, 2006, 09:14:45 am »

Real hard coded pointers are actually individual assembly instructions for each string. I've dealt with that crap more than once.

game code:
lda #$3b67   ;load the hard coded pointer
tay                ;store in the index
lda [$76],y    ;load the string

There can also be hard coded 24-bit pointers or even 32-bit pointers in a similar fashion. They have dedicated assembly code that calls each string. If you have alot of these, you should get a pad ready for the wall when you head bangs into it. Sometimes you can write a utility to recognize the code pattern if it is always the same, but other times.. you may be out of luck.

« Last Edit: December 06, 2006, 12:29:04 pm by Nightcrawler »
byuu
Guest
« Reply #32 on: December 06, 2006, 11:44:26 am »

"tay $76" ... what processor are you coding for again? Tongue
Nightcrawler
Guest
« Reply #33 on: December 06, 2006, 12:34:16 pm »

Give me a break. I code for so many damn processors and microcontrollers, I get them mixed up all the time. Not only do I get instructions mixed up, I get usage mixed up, parameters and more. Thankfully, the assembler won't let me get away with things like that. Wink

Be happy that was the only mistake coming out of my head! It could have been much worse Tongue
Pages: 1 2 [3]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC