+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Atlas Trouble
Pages: 1 [2]
Author Topic: Atlas Trouble  (Read 1163 times)
Kitsune Sniper
Guest
« Reply #15 on: March 29, 2007, 07:11:38 pm »

Quote from: Gemini on March 29, 2007, 06:40:06 pm
Quote from: Kitsune Sniper on March 29, 2007, 06:23:19 pm
No it won't. I use this and it doesn't change the pointer order at all. :p
And I tell you it will. CT's pointers do not match the script order, so repointing everything from the script structure will cause the game to display some sentences instead of others. Roll Eyes

And I'll tell you that Atlas does not need to reorder the pointers at all.

Lupin, Ys III, Samurai Pizza Cats and Armadillo have sequential and non-sequential pointers; You can tell Atlas to write down a pointer at a location you choose, when you choose to, instead of telling it to write them all automatically. You only have to create a custom pointer definition, and add a #WRITE(MyPointer, $xxxxx) before each block of text you're adding. As an example:

#WRITE(MyPtr, $21660)
Look,it's

a Martian![E]

That's telling it to write a pointer to the text at $21660. The block after that? It can have a pointer at $200F0, and the program won't care, it'll still write it. You can also tell the program to write the same value to different locations at the same time. A few of the blocks in Armadillo have two pointers because they're called at two different times in the game. In that case, I just added two #WRITE parameters.

I'm guessing you're using Atlas' classic pointer writing method, correct? Well, that won't work with some games, you have to define a specific formula in these cases. Just like I always have.

Edited to remove dyslexic sentences Tongue
Gideon Zhi
Guest
« Reply #16 on: March 29, 2007, 07:22:43 pm »

Alternatively, you can reconstruct the entire pointer table using Atlas's embedded pointer function, and simply associate each pointer with its proper string. None of the SNES SRW titles have their pointers ordered by string address (i.e. the first stored string does not necessarily correspond to the first pointer) but Atlas can handle them just fine.
Deuce
Guest
« Reply #17 on: March 29, 2007, 07:35:01 pm »

Quote from: Kitsune Sniper on March 29, 2007, 07:11:38 pm
You can also tell the program to write the same value to different locations at the same time. A few of the blocks in Armadillo have two pointers because they're called at two different times in the game. In that case, I just added two #WRITE parameters.

I'm no hacker, but I had to mess with three Atlas-type scripts (Cyber Knight II, Ys IV and V), and I can attest to this.  Ys IV's script was waaay out of order, and I was able to physically move strings in the text file to the right place to put everything in its ingame order (for better context editing).  No problems whatsoever.
Gemini
Guest
« Reply #18 on: March 30, 2007, 08:03:25 am »

Quote from: Gideon Zhi on March 29, 2007, 07:22:43 pm
Alternatively, you can reconstruct the entire pointer table using Atlas's embedded pointer function, and simply associate each pointer with its proper string.
Isn't that a bit time consuming? Tongue I mean, dumping directly using pointers would have taken the problem out in a second.
StIoachim
Guest
« Reply #19 on: March 30, 2007, 09:46:59 am »

Quote from: Nightcrawler on March 29, 2007, 11:35:13 am
I know exactly what you're asking and I'll give you the answer you want:

MSVCP70.DLL contains C++ run time library functions for .NET.

Therefore, the installed thing you're missing is .NET. Wink



Wouldn't it be Microsoft Visual C++ 2003 Redistributable, or it's included in .NET Fx 2003, I don't remember quite well...
DarknessSavior
Guest
« Reply #20 on: March 30, 2007, 09:58:12 am »

I actually haven't been able to install the .NET package; if I could, I'd have been able to use Temporal Flux for my original CT hack. Luckily, I'm getting a new PC soon, so I'll be able to put it on THAT PC. ^_~

~DS
Nightcrawler
Guest
« Reply #21 on: March 30, 2007, 11:38:08 am »

StIoachim:

Yes. Your are also right. Those DLL's are part of:

The main .NET installation
Microsoft Visual C++ Redistributable,
.NET Fx

Any of three should work. Of course, it's simplest just to download the dll files themselves and stick them in the Atlas directory. In this case you're not missing out on much by not installing any of those packages. If you install them, they may help you in future with other files, but other than that, it wont' do you much good. Your system is probably too old to run .NET efficiently anyway.

Atlas isn't really a .NET application. It just was made in Visual Studio .NET and uses updated C++ library files in Windows.
Gideon Zhi
Guest
« Reply #22 on: March 30, 2007, 05:23:40 pm »

Quote from: Gemini on March 30, 2007, 08:03:25 am
Quote from: Gideon Zhi on March 29, 2007, 07:22:43 pm
Alternatively, you can reconstruct the entire pointer table using Atlas's embedded pointer function, and simply associate each pointer with its proper string.
Isn't that a bit time consuming? Tongue I mean, dumping directly using pointers would have taken the problem out in a second.

Could have done that, yes, but doing so would have mucked up the text order for the translator and editor. I'd rather spend a little extra time constructing the pointer tables myself than have my translator or editor (especially when I'm my editor) confused.
Klarth
Guest
« Reply #23 on: March 30, 2007, 09:23:57 pm »

Kit, the proper implementation of a pointer table with nonsequential strings (in my eyes) is to use a pointer list, but I don't think anybody uses those.  Gideon explained the method he developed using embedded pointers to do the same thing.  But #WRITE type commands were all that the private Atlas versions used, so it's still quite effective, but more work on your part.  I'm proud to say that Atlas can do the same task in several ways and do things that I didn't plan, such as the embedded pointer thing.
Gideon Zhi
Guest
« Reply #24 on: March 30, 2007, 09:31:15 pm »

For the record, I only use the embedded pointer thing to make a pointer table more easily relocatable. If you define a table using Atlas's built-in commands, you have to define an address for that table - with a table made up entirely of embsets, you can move it around dynamically as the situation desires, including by simply adding or removing text from the block immediately before it.
Klarth
Guest
« Reply #25 on: March 30, 2007, 09:42:41 pm »

Good points.

Btw, on an off topic note.  My laptop should be arriving tomorrow, but I don't have WinXP nor Visual Studio, so I won't be doing much on it until then.  Afterwards maybe I will.
Kitsune Sniper
Guest
« Reply #26 on: March 30, 2007, 10:22:20 pm »

Quote from: Klarth on March 30, 2007, 09:23:57 pm
Kit, the proper implementation of a pointer table with nonsequential strings (in my eyes) is to use a pointer list, but I don't think anybody uses those.  Gideon explained the method he developed using embedded pointers to do the same thing.  But #WRITE type commands were all that the private Atlas versions used, so it's still quite effective, but more work on your part.  I'm proud to say that Atlas can do the same task in several ways and do things that I didn't plan, such as the embedded pointer thing.
Part of the problem (with me) is that I often take the translated script and add the pointers as I poke around in the rom. I don't have the patience to write pointer lists or to figure out what pointer points to what before using Atlas. Tongue
Pages: 1 [2]  


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