Need to use libiconv on Windows. libiconv doesn't accept all of the same
encoding names as the glibc iconv. In particular, CP932 needs to be used
instead of SJIS-WIN.
Use iconv instead of utfsjis.h so that text encodings other than UTF-8
and SJIS can be used. For three reasons:
* to allow using other encodings for dumped files (e.g. UTF-16, SJIS)
* to support existing Chinese translations, which use GBK-encoded text
* to support theoretical translations to other languages that can't be
represented in SJIS
Very incomplete implementation. Capable of reading the file table and
not much else.
Also add the "alice-ar" utility for testing. Eventually this tool should
support modifying ald and afa archives. For now only supports dumping
the afa file table.
The -s,--split option to exdump can be used to split the dump into
multiple files (one per top-level data structure). The output file when
using the split option contains #include directives to stitch the full
dump back together when given to exbuild.
Tool for reading and rebuilding dumped .ex files. Currently this only
reads a file on stdin then redumps it to stdout.
Also, move tools code into src/tools/
Add tool for dumping the contents of .ex files, which contain various
structured data used by the game (tables, lists, trees).
The dump format uses a C-like syntax which should be relatively easy to
parse back in.
Use enums for long option values, and run dumps in the order they're
specified on the command line. Also, --no-strings mode is made the
default and a --inline-strings option is added to get the old (broken)
behavior.
Add -t,--text option to read files produced by 'aindump -t ...'.
The workflow here is:
* dump the text with 'aindump -t -o <outfile> ...'
* $EDITOR <outfile>
* locate the text you want to edit, remove the leading semicolon (i.e.
uncomment it) and edit the string as desired.
* reinsert the modified text with 'ainedit -t <outfile> ...'
If the filenames section isn't present, try to guess the filenames from
the functions defined in the file. This works pretty well for most of
the core engine files but gives pretty crappy results for scenario
files.
This feature is primarily intended to be used when dumping the code
section to multiple files (not yet implemented).
Add a pseudo instruction to represent switch case labels, along with the
infrastructure to support pseudo instructions in general. .CASE takes
two arguments: a switch:case index (e.g. "12:8") and the value to match
against.
Also, add a --no-strings option to both programs to allow modifying the
code without changing the string/message tables. This is needed for now
since rebuilding the string/message tables (as currently implemented)
causes serious bugs in Rance X (and probably other games).
Running the following command should produce an ain file that is almost
bit-for-bit identical to the input file (the only difference being minor
drift in floating point constants):
aindump -c --no-strings in.ain | ainedit -c - --no-strings -o
out.ain in.ain
The ainedit utility is a tool capable of modifying AIN files up to
version 12 (Rance X). As far as I know, this is the first publicly
released tool that can handle AIN files above version 7.
The basic mode of operation is as follows:
* dump the CODE section with aindump
* edit the disassembled bytecode
* assemble & insert the edited bytebode back into the original AIN file
using ainedit
E.g.
aindump -c -o out.jam /path/to/Rance10.ain
$EDITOR out.jam
ainedit -c out.jam -o out.ain /path/to/Rance10.ain
mv /path/to/Rance10.ain /path/to/Rance10.ain.backup
mv out.ain /path/to/Rance10.ain
ainedit is also capable of editing declarations (structures, functions,
etc.) using the JSON (-j) output from aindump.
There is currently one major deficiency in this tool: it does not
rebuild the AIN file's switch table (SWI0 section). This means that you
can't insert or delete instructions, as it would render the addresses
stored in the switch table invalid. I hope to fix this soon.
A number of changes have also been made to the aindump utility, since
these tools need to work together.
Don't generate SJIS with initial byte 0x80. I'm guessing that sjis2utf
handles initial byte 0x80 the way it does for compatibility reasons, but
there is no reason for utf2sjis to generate this coding.
Dump everything except the code to a JSON file.
With both the disassembled code and this JSON file in hand, it should be
possible to reconstruct the original AIN file.
Keep a stack of functions which gets pushed/popped on FUNC and ENDFUNC
instructions, respectively. Since methods do not get an ENDFUNC (for
whatever reason), this stack has to be a fixed size and discard the
oldest value when pushed to (otherwise it would grow indefinitely).
This fixes a bug when dumping the code of Ixseal, where a lambda's
ENDFUNC would clear dasm->func while the parent function was still being
disassembled. Interestingly, this doesn't become an issue in Rance X
because the code is more indirect in how it accesses local variables (no
SH_LOCAL* instructions).
This requires scanning through the code for a particular method for each
enum type. Not a great solution, but there's not much else that can be
done here.
Also, use khash.h (from klib) for hash tables.
In ain v11+, the first and only argument to CALLMETHOD is the number of
arguments that are being passed to the method. The calling convention
is:
PUSH <struct page>
PUSH <function index>
PUSH <arg 0>
...
PUSH <arg n>
CALLMETHOD <n>
Type 82
-------
I am assuming this is an iterator type because it always appears as a
local variable alongside "dummy" variables with "foreach" in their name,
and the naming of the variables suggests an iterator. Probably there is
a new syntax like:
foreach (iter_var in array_var) { ... }
Type 89
-------
An instance of an interface. This is a 2-valued type (similar to ref
int, etc.) where the first value is the index of a struct page, and the
second value is an index into the struct's vtable.
Any struct that implements an interface gets an array<int> named
"<vtable>" as its first member. This array stores indices into the
global function table. CALLMETHOD now looks up methods in the vtable
rather than the global function table.
Types 92, 93
------------
These are enum types. Type 92 is the normal enum type, and type 93 is
the reference-to-enum type. The "struct type" for these types stores an
index into the enum table.
Types 86, 91
------------
Type 86 only seems to be used as the return value from EnumType::Parse
methods. In the ain file, it has an extra type descriptor, similar to an
array type. This extra type descriptor always has data type 91, and its
struct type is an index into the enum table. Type 91 is simlar to types
92 & 93: it stores an enum table index in its struct type.
Type 86 is a 2-valued type. The first value is the value of the enum (an
integer between 0 and n). The second value seems to be either 0 or -1,
depending on whether EnumType::Parse was able to produce a valid enum
value.
It is possible that type 86 is actually some kind of generic maybe-error
type that only happens to be used by the enum code. But that doesn't
explain why it is paired with type 91 and not type 92.
Print the new v11+ array types properly. Also, print the array rank for
old array types.
The code for reading v11+ ain data is simplified a lot here as well.
I've figured out what most of the extra fields are for. Mostly they are
for:
* a new array type, in which the contained value type is stored in the
variable object rather than encoded in the type number
* argument initvals (I guess the VM is now responsible for these?)
* interfaces
Use the correct argument types for all instructions, with the exception
of SH_REF_LOCAL_ASSIGN_STRUCTREF2 which I could find an example of.
List all system calls.
v11 ain files have 3 new instructions, and 3 modified instructions. It
looks like they decided to break compatibility with this release by
adding arguments to some instructions.
v12 adds one instruction.
Nunuhara Cabbage