Author
|
Topic: Cartographer (Read 2 times)
|
RedComet
Guest
|
 |
« on: December 29, 2008, 02:50:34 pm » |
|
http://www.rpgclassics.com/subsites/twit/progs/Cartographer_PR3.zipI've included a sample of how the dump by pointer and raw dump (like romjuice) methods work using FF1 as an example. I still need to write a few more examples, but I need to find games that I'm not actively working on to demonstrate the features on. Everything should be complete, but there may still be bugs, which is the whole point I'm posting this. Use it and report any bugs you find.
|
|
|
|
|
Kagemusha
Guest
|
|
« Reply #1 on: December 29, 2008, 03:06:08 pm » |
|
There's this NES game called Jajamaru Gekkimaden or something that doesn't use control codes and the only way to find where a string begins is by looking at the pointer table. At least that's how I remember things. Could be a possible example.
|
|
|
|
|
Vehek
Guest
|
|
« Reply #2 on: December 30, 2008, 07:55:15 pm » |
|
I don't understand how to use this. Do I need to set up my table a certain way?
"#0: Line 1: First character of the line is not a recognized table character"
Edit: Is this because my table's in UTF-8 encoding?
|
|
|
|
« Last Edit: December 30, 2008, 08:17:08 pm by Vehek »
|
|
|
|
Tauwasser
Guest
|
|
« Reply #3 on: December 30, 2008, 08:29:53 pm » |
|
Seriously, if this does not support unicode, nobody here wants it anyway. Can't be that hard to make it unicode compliant...
cYa,
Tauwasser
|
|
|
|
|
RedComet
Guest
|
|
« Reply #4 on: December 31, 2008, 11:40:05 am » |
|
I don't understand how to use this. Do I need to set up my table a certain way?
"#0: Line 1: First character of the line is not a recognized table character"
Edit: Is this because my table's in UTF-8 encoding?
Could you send me your table file so I can check it out? |
|
|
|
|
Vehek
Guest
|
|
« Reply #5 on: December 31, 2008, 12:47:28 pm » |
|
Is e-mail okay?
I didn't have any problems when I tried using a table in ANSI format.
|
|
|
|
« Last Edit: December 31, 2008, 01:08:57 pm by Vehek »
|
|
|
|
RedComet
Guest
|
|
« Reply #6 on: December 31, 2008, 01:15:22 pm » |
|
|
|
|
|
|
C_CliFF
Guest
|
|
« Reply #7 on: January 01, 2009, 10:19:22 am » |
|
I just tested the program with an old project I had, FF5. I don't know if the program has a bug but when I try to extract a block that uses 3-byte pointers the program crashes. This is my commands (I tried to explain as well as I could):
#GAME NAME: Final Fantasy 5 (SNES)
#BLOCK NAME: Dialogue Block (RAW) // this raw block extracts fine
#TYPE: NORMAL
#METHOD: RAW
#SCRIPT START: $21020D
#SCRIPT STOP: $21FE16
#TABLE: ff5_raw.tbl
#COMMENTS: Yes
#END BLOCK
#BLOCK NAME: Dialogue Block (POINTER_RELATIVE)
#TYPE: NORMAL
#METHOD: POINTER_RELATIVE
#POINTER ENDIAN: LITTLE
#POINTER TABLE START: $2015F0
#POINTER TABLE STOP: $202F3F
#POINTER SIZE: $04 // see POINTER SIZE comment below
#POINTER SPACE: $00
#ATLAS PTRS: Yes
#BASE POINTER: $210200 // see BASE POINTER comment below
#TABLE: ff5_ptr.tbl
#COMMENTS: Yes
#END BLOCK
// POINTER SIZE: This is were the program crashes. The game uses 3-byte pointers
// so I changed it to 04 like the readme said. I tried just for testing
// to change the value to $02 and then it extracted fine. But
// like I said, since the game uses 3-byte pointers then the pointers
// are wrong. Besides, the script doesen't look like it should.
// BASE POINTER: I'm not sure exactly how this one works. To get the right adress
// to the pointer table you subtract 200 and then add C00000 to get the
// right value to calculate the pointers so I don't really know if
// I made it right. I tried and remove POINTER_RELATIVE metod and changed
// it to POINTER and then removed the BASE POINTER method but the program
// still crashes.
-C_CliFF |
|
|
|
« Last Edit: January 03, 2009, 08:34:45 am by C_CliFF »
|
|
|
|
RedComet
Guest
|
|
« Reply #8 on: January 04, 2009, 07:14:33 pm » |
|
The base pointer is the value you that you either add or subtract to the pointer in the table to get the string address. Take the string address and subtract the pointer value from the address. The difference is the value that you must add to the pointers to get the string address, therefore it's the base pointer.
As for the table accepting unicode -- it should, but I'm using Klarth's table library, so if that doesn't then Cartographer doesn't either. I'll test that out.
I'll address those other issues this week hopefully. Short on time.
|
|
|
|
|
Vehek
Guest
|
|
« Reply #9 on: January 04, 2009, 07:23:10 pm » |
|
I haven't tested it yet, but my problem might have to do with UTF-8's "byte-order mark".
Edit-Tested it by cutting the byte-order mark out with a hex-editor, and the table worked.
|
|
|
|
« Last Edit: January 04, 2009, 09:18:25 pm by Vehek »
|
|
|
|
Tauwasser
Guest
|
|
« Reply #10 on: January 05, 2009, 02:29:05 am » |
|
Seriously, there gotta be a standard library that can use all file types, be it Unicode, ± BOM, ANSI... It should encourage Unicode of course. And yes, Unicode can be UTF-7, UTF-8, UTF-16, UTF-32 ± BOM or UCS-2, UCS-4 ± BOM! Seriously, I don't get what's so hard about making a unicode compliant program. What is this? 1998?? It's 10 years after Unicode was invented guys, wake up and use it properly!
If there is no ready-to-use c library/header/whatever for this, then it's a shame. I doubt it tho, Microsoft can do it, so can you.
cYa,
Tauwasser
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #11 on: January 05, 2009, 08:43:21 am » |
|
Quit being so harsh, especially since you are seemingly ignorant on supporting Unicode formats in C/C++ (assuming this utility was written as such). It's not as trivial as you make it out to be. Suggesting Unicode support is strongly needed is one thing, being as ass about it is another. Offer some assistance if you're going to be so demanding. This is another example of why I have never, and probability never will, release a public utility to this community. These kind of reactions make me ill.  |
|
|
|
|
byuu
Guest
|
|
« Reply #12 on: January 05, 2009, 11:39:38 am » |
|
// POINTER SIZE: This is were the program crashes. The game uses 3-byte pointers
// so I changed it to 04 like the readme said. I tried just for testing
// to change the value to $02 and then it extracted fine. ... am I the only one who wondered why you weren't supposed to use a value of $03 to represent a 3-byte pointer? :/ And yes, Unicode can be UTF-7, UTF-8, UTF-16, UTF-32 ± BOM or UCS-2, UCS-4 ± BOM! Seriously, I don't get what's so hard about making a unicode compliant program. Windows internally uses UTF-16 only. Linux uses UTF-8 only. You can feed it whatever format you want, but you have to manually convert it. Easy to get cross-platform support by writing a MultiByteToWideChar(CP_UTF8...) wrapper for 'doze. Losing O(1) character lookup sucks royally, though. UTF-16 can't do that 100% cleanly thanks to surrogate pairs. Sure you can ignore those, but yuck. So you can use the even less common UTF-32, fun. I just make sure my UTF-8 tables use characters that encode as 3-bytes/per so I can be cheap about indexing. The ROM hacking scene has always been about ten years behind the common encoding format, anyway. When I started, it was all about EUC-JIS encoding. Be happy most are at least using Shift JIS now. |
|
|
|
|
Tauwasser
Guest
|
|
« Reply #13 on: January 05, 2009, 01:12:08 pm » |
|
So, seriously, I have no idea of c/c++, but I'm freaking sick of seeing programs not work for many people because it only supports latin-1 or whatever. I'm just saying, that there is a way, Microsoft does it - so can everybody else with a little effort. There just has to be a standard library in c/c++ by now that features text file access that does not read ANSI only or crashes on BOM, valid unicode etc. And yes, by now I think the translation community - especially the translation community - ought to care about that stuff. Cartographer might be nice, however, I'm running a Japanese OS, so it probably won't work for me with German umlauts etc. That's a problem! And there is a solution. And it has been around for 10 years. I just can't believe there is no library in c/c++ or whatever this is written in that supports this! Windows internally uses UTF-16 only. Linux uses UTF-8 only. I'm not talking about filenames. The .Net framework is pretty darn good at reading all of those formats (though I didn't test UTF-32, but I read it somewhere... I tested UTF-8, UTF-16 and UCS-2 tho). You don't need to convert not textfile for it to be able to read it with StreamReader! And it's not only the romhacking community. IrfanView doesn't even support UTF-16 filenames! HexWorkshop didn't, but the newest release does! However, it seems so slow compared to other apps (and yes, Microsoft apps!) that work seamlessly and without ANSI and have been working so for years! cYa, Tauwasser |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #14 on: January 05, 2009, 01:27:48 pm » |
|
Few points: 1. To take advantage of Unicode (UTF-16) on Windows using straight Win32 C, you need to do a bunch of little things including using all 'W' versions of the library functions and variables such as LPWSTR for strings. And don't forget the 'L' in front of a declared string in your code. One time I had a large Win32 program made. A few years later, the company wanted Unicode support added. Converting after the fact was nearly unfeasible. I spent some time with it, but there were so many things to change and so many small errors cropped up, I told them it wasn't worth their time and they should instead include Unicode in the next generation application where it can be added properly into the design rather than kludged to hell after the fact. Converting between character sets is also somewhat painful. Apparently it's not intuitive enough because I've clean forgot off hand how to do it. Unicode in Win32 can be a real pain, especially if you didn't plan for it from the beginning! 2. If you're just using standard C or C++, same story really. You need to use the 'w' versions of the common functions and string/char variables. You still have some issues converting, but I think you can use something like setlocale(), iconv() or something for the output you desire. It's been so long since I didn't anything in plain vanilla C/C++, I don't remember nor did I really do much there involving Unicode. 3. Any .NET language makes character encoding handling insanely easier on Windows. Unicode is always used internally, but you have the freedom to input and output most anything easily. You want S-JIS for input and UTF-8 for output? Or vice versa? Not a problem. For people like myself scarred from former character encoding headache nightmares, they all went away with .NET.  It's not surprising that many English made ROM hacking tools don't support Unicode well. So.... RedComet, what did you program the utility in? |
|
|
|
|
|
RHDN Forum Archive
