This is part 2 of a multi-part series.
Everyone needs some structure
In the last part, I went over the basics of analyzing values in an exported project, but this doesn't explain how to get actual data out of the scene. To skip ahead a bit, one problem is that objects in mTropolis aren't the same size. Without any knowledge of the structure, we aren't really even sure how to determine where objects start and end, and that can be a bit difficult.
A simple way of dealing with variable-sized objects is just make multiple identical ones and see how far apart they wind up in the data. It also isn't entirely clear yet how the stream catalog even associates with scenes in the project tree.
Let's export it and use MTDisasm's "bin" mode to dump the streams, then open up stream-3-1.scene for the Mac and Win versions in XVI32 again.
Also of interest, there is a 32-bit value that is 8 only in the last one - This turns out to be a flags field, and the 8 is a bit flag indicating that the element is the last one in the list of elements for that level of the tree.
(Fun fact: One of the flag bits is for if the object is expanded in the structure window, which is useless outside of the editor.)
The start of the element also provides some useful clues, which led to figuring out the format after investigating different types of objects: Most (but not all!) object types start with a 32-bit object type ID, a 16-bit revision number, a 32-bit field of unknown usage, and a 32-bit size that includes the preceding values.
Unfortunately, while the first 2 values are common across all objects, the next 2 are not always followed. That turned out to be a problem when a fallback handler for unknown object types was sometimes flying off outside of the data due to the size field not actually being there. Plug-ins (which we'll get to later) are particularly weird, with the size value being garbled, but still decodable, only on Windows.
That's no scene
There is actually an unusual quirk here: That piece at the start of the file is not the scene definition. One way that you can tell that it isn't is that if you add modifiers to the scene, they don't show up in the scene stream, they show up in... the boot stream?
Well, now we get to one of the weirder aspects of mTropolis's architecture, a quirk that actually causes an annoying bug in the Windows version of Obsidian. The object at the start is some kind of stream header, of unknown purpose. The definition of the actual scene object is not stored in the scene stream, it's stored in the boot stream and it always exists, but the objects inside of them are loaded on-demand.
Not only that, but scenes aren't really even scenes. Projects have their own type, as do sections and subsections, but scenes are just graphic elements... or at least they are most of the time. If you link them to an image or QuickTime movie, they change type into that kind of element, so scenes are actually the same type of object as a scene element.
So what is the bug in Obsidian that this causes? It's the bug where if you trigger the rebellion music in the first chapter, and then go the wrong way, the music keeps playing forever, even if you restart the game, because the MIDI modifier that plays the music is directly under the scene in the project hierarchy, preventing it from ever being unloaded. The Mac version fixes this issue by... deleting that music track.
An informative experience
The strategy for MTDisasm for the most part has been to create structures for all of the data types, byte arrays by default if all of the values seem to be the same, and larger values if they have visible byte swaps. Fields with unknown use are named "Unknown" with a number after it, and for convenience, if an unknown field turns out to be multiple values, it is not renumbered, but rather split so other values maintain their number. For example, if a field named unknown3 turns out to be 2 values, it is split into unknown3_1 and unknown3_2.
Here's what our test scene looks like cranked through MTDisasm's text mode today:
An inconsistent experience
Let's take one of the more minor examples of how this can go wrong by creating a floating point variable modifier and setting its initial value to pi.
So far so good, export the files, dump the streams with MTDisasm bin mode and...
Uh oh, something is very wrong here! The Windows version has a value in it that XVI32 is telling us looks like a double-precision float encoding pi at the end, but the Mac version is 2 bytes longer and looks pretty different. What is going on?
Let's think like a Mac programmer here: Motorola 68000 CPUs didn't originally have floating point support, and when they did, it was added via the MC68881 FPU add-on, later incorporated into the 68040 CPU. That FPU preferred float data in an 80-bit format, with a 16-bit exponent and 63-bit mantissa with a required 1 bit for finite numbers above the mantissa.
That format has a few advantages, such as being relatively efficient to work with on CPUs that only support integer arithmetic, but the specifics of floating point behavior are well-documented in other places, and the important thing here is that the Mac and Windows versions are using completely different number formats for floats.
This behavior exists in some other places too: Color values on Mac are 6 bytes per color (due to Macs having 16-bit precision per channel), but 4 byte BGRA format on Windows. The auxiliary data in QuickTime elements is particularly different, with 14 extra bytes in the header on Mac and 12 extra bytes in the footer on Windows.
Interactivity: A machine built out of mail
Now that we've covered much of how the data is structured, it's time to talk about what is either the best or worst feature of mTropolis: Object behavior and communication.
Almost everything that makes objects interesting in mTropolis is accomplished via modifiers and messages. Modifiers are a special type of object that can be attached to scene elements (and, in a few specific cases, other modifiers), making them do things. Importantly, many modifiers do not really modify the object, but provide other functionality, and simply exist as modifiers. Variables, for instance, are modifiers. Saving and loading games is a modifier. Scripts are modifiers.
Also central to this is one of mTropolis's most important features: Behaviors, which are containers for other modifiers. Behaviors can be switchable, allowing them to be turned on and off, potentially turning off all of the modifiers inside of the behavior, and they can also be aliased, allowing you to save a behavior into the alias palette and reuse it across multiple objects.
Inter-object and inter-modifier communication is done via messages. Most modifiers trigger when they respond to a message, and the message is either a built-in message type (such as a "Mouse Over" message firing when the mouse moves over an element) or a custom message type created by the author. Messages can usually be sent with a value as well, potentially affecting how the recipient responds.
Recreating mTropolis's behavior requires extensively testing what messages fire when, and in what order. Sometimes the order is complicated. For instance, message senders usually have an "immediate" flag that determines whether the message sends immediately (before the message currently being propagated continues propagating), or is added to a message queue. When the message queue is processed was behind a bug where the Statue area was playing the wrong music because it turns out that if a non-immediate message is sent, and then something causes a scene transition, the queued-up message has to be sent after the scene transition.
Weird code in the land of no code
It turns out that having a spaghetti of message senders and recipients isn't really enough to express your game logic efficiently all of the time, so mTropolis does supply a scripting system in the form of the Miniscript modifier.
Miniscript is infamous for being hobbled by intentionally not having any loop constructs to encourage developers to use things other than code instead. If you want a loop, you either have to queue up a message of some kind to re-trigger the modifier, and possibly chain things together. That's really only the beginning of its problems though, it's full of weird cases where the semantics aren't really clear at all. For example, as mentioned earlier, variables are modifiers, but if you use a variable from a script, it may treat it as referencing the value of the variable or referencing the variable modifier itself, depending on what you're doing. What triggers the implicit conversion of a variable to the value it contains? Who knows, just have to endure the bugs and find out.
One case involves a bunch of things being miscompiled in Obsidian due to a design fault that is invisible, and impossible to fix without trashing the project and starting over. For example, let's look at the Miniscript modifier with GUID 0034164d, named "Init on PE". Here's what MTDisasm currently tells us that it says when decompiled:
if element.width <> 640 then
set element.width to 640
end if
if element.height <> 360 then
set element.height to 360
end if
if element.visible <> true then
set element.visible to true
end if
if element.position <> (0, 0) then
set element.position to (0, 0)
end if
if element.direct <> true then
set element.direct to true
end if
if element.paused <> true then
set element.paused to true
end if
if label:(4:3ae) <> true then
set element.loop to true
end if
... What?
What is going on with this last one? What is a label?
Well, let's say you write this code in Miniscript:
if loop <> true then
set element.loop to false
end if
What have you actually written here? When you save a Miniscript modifier, if there is an identifier like "loop" in this case, then it first tries to resolve it to a global value. If that fails, then it has to look it up, which internally is done using a subscript (i.e. by looking up a value "contained in" something else). At first I thought the thing it was subscripting something that meant, basically, "go look for it." Nope. The default thing to subscript is the current element, but if you subscript an element by name, it will still look further up in the scene hierarchy for that object.
The exact search order had to be sussed out through via repeated tests, cause you really don't want to be looking up the wrong thing, do you?
MTDisasm will add some additional annotations to note how a value is being resolved. But what is a label? Well, in this case, mTropolis supports a feature where you can embed time markers in AIFF sound files, and then allow those time markers to trigger a media cue modifier, among other things, but those time markers are named, and those names go into the global label table. In this case, someone imported a sound file with a time marker named "loop."
There is no way to view the global label table, there is no way to delete a label after it's been imported, and the labels permanently become names that identifiers in scripts resolve to.
So, some poor sap is now comparing the value of a sound marker to "true" instead of the element's "loop" property like he would have been if that sound file was never imported.
Another thing that must be handled properly when running Miniscript is errors. Many errors will terminate a script execution, while some things (like sending a message to an object that doesn't exist) will not, and games have code that doesn't work correctly if that behavior isn't mirrored correctly.
Garbage in, un-garbage out
How are we even getting these scripts back though? Do the Miniscript modifiers just have the program source in them? Well, in very early versions of mTropolis, yes. In every shipped title I've seen, no, the export process removes the Miniscript code and only leaves in a compiled version.
Let's take a look at the Miniscript object that we just mentioned in Obsidian.
After isolating the values, we see what we're looking at. Quick note: The reason for the "program header" is that there are actually two modifiers that use Miniscript programs: The Miniscript modifier, and the "If Messenger Modifier" which uses a Miniscript program to evaluate a condition.
In this case, there are no references. A reference is just a name and an object GUID. There is a field indicating the size of the instruction data, which looks like a blob of... stuff. It's not aligned, so the instructions aren't fixed-size. Let's look a bit closer.
If we look carefully, there is a bit of a pattern here. Each instruction has a size 4 bytes in, which makes it possible to isolate individual instructions. Convenient!
The first guess of how this works, which turned out to be correct, is that this is a stack machine, one of the easiest ways to write a scripting system. The way a stack machine works, for the unfamiliar, is that instructions do some combination of removing ("popping") values from the end of a list and appending ("pushing") new values to the end of the list ("stack"). For example, if you had to evaluate the expression:
((A*B)+(C*D))
Then the stack machine instructions would look something like:
push A
push B
multiply
push C
push D
multiply
add
After a lot of messing around, this is what MTDisasm outputs for the instructions of that first condition block:
0: push_global default
1: get_child 00000000
2: push_value double 640
3: cmp_neq
4: jump conditional unknown=62 skip=5
5: push_global,args=1 default
6: get_child,args=1 00000000
7: push_value double 640
8: set
Okay so what are these? "default" in the disassembly really means "element" but what we are doing here is pushing the value of "element" and then getting the attribute with index 0 from the attribute list (which is "width"), then pushing the value 640.0, doing a comparison (which pops the last 2 values from the stack and pushes true or false on to the stack. Then it does a conditional jump based on the value, and if it's false, skips to 5 instructions ahead. If that skip didn't happen, it pushes the element (with a write-intention flag in the arguments!), gets the child (also with a write-intention flag), pushes the value 640.0, and then runs a set operation that applies the value.
One irony here is that it would have been extremely easy to add support for loops into this by just allowing negative offsets in the jump instruction, the developers simply chose not to because... reasons?
This is kind of hard to read though, so what can we do? We decompile it!
Stacking boxes
Decompilation for something like this normally involves 2 steps: Converting stack machine instructions back into expression trees, and converting the control flow graph back into structured control flow.
The first one is straightforward, since Miniscript never has branches in the middle of an expression. Remember that pseudocode for the stack machine I had earlier? Well, if you just keep track of each input to something that consumes values from the stack, you can just regurgitate them into expression text. The only thing complicated there is some precedence analysis, which is done to avoid having to put parentheses around everything... It also doesn't quite work right, if I remember, but it works enough that I can tell what's going on.
Control flow analysis, which involves converting jumps back into if/else/end if blocks, is the harder part. Let's say we right a script that roughly looks like this:
if A then
do something A
else
do something B
end if
do something C
This will compile into stack machine code that looks something like this:
0: push A
1: jump conditional to instruction 4
2: Do something A
3: jump to instruction 5
4: Do something B
5: Do something C
These "Do something ..." blocks can be any number of instructions. In order to decompile this, we need to convert it into a control flow graph. Control flow graphs in modern compilers can be quite complicated, especially if they form loops, but since Miniscript doesn't have loops, we're left with what's called a directed acyclic graph, meaning no path through the graph ever flows through the same node more than once.
To do this, we split sets of instructions out into blocks. A block starts with any instruction that is the target of a jump, and ends with either a jump instruction or where another block starts.
Note that there is an "end of program" block. This block is always added to the end and contains no instructions, but it's useful for the decompile algorithm.
So how do we work with this?
First, for each one of these nodes, we have to determine several pieces of information about it:
- Immediate predecessors (which nodes directly flow into the node)
- Immediate successors (which nodes it can directly flow into)
- Post-dominators (which nodes must be flowed through after the node)
I'm sure there are better ways to do this, but the way MTDisasm does this is by creating "islands" that each correspond to an emittable block of code. All islands start with a block of code and end in a "sink" which exits the island. Initially, there is one island that starts with the first block and sinks into the "end of program" block. It then repeatedly processes islands until it's done, and each time an island is processed, it can produce additional islands that also must be processed.
Processing an island is done as follows:
First, check if there is more than one post-dominator of the starting block. If there is, then we need to find one that terminates the island. Post-dominators are always reached in a fixed sequence, so we can find it by just following the first successor until we hit the first post-dominator. The island is then split into 2 islands, one that sinks into the post-dominator, and one that starts at the post-dominator (with the original sink).
Then, the successor list of the block is checked. For each successor, it checks if there is an island starting at that successor already. Doing that handles "if" statements that have no "else" block and go to a successor of the "else" block when the condition is false, for instance. If there is no island starting at that successor, a new island is created, starting with that successor's first block and ending in the original island's sink. Since we know the island is now post-dominated by its sink, we know that is the end of the control flow path of the new island.
This process is repeated until there are no islands left.
After that, we convert the islands into code. Starting with the first island, the island's instructions are converted back into an expression tree and emitted. Then, if the block ends in a condition, an "if" statement with the condition expression is emitted, followed by the "true" island, and an "else" followed by the "false" island if present, and then an "end if", followed by the sink island (which can chain into more conditions and sink island).
That's it! We can now see the code!
The last format standing
Most of the other data can be figured out using this test-case analysis. Create a bunch of the same thing, change one thing, see what changes. Some things are formatted interestingly, like a lot of things have a "rate" parameter which is actually exported as a large value divided by the rate, turning it into a delay instead.
Most of the asset formats are fairly straightforward too. Images are flipped and have different channel order on Windows, but otherwise are uncompressed. Audio is uncompressed. Sometimes things are compressed, but are compressed with a QuickTime codec and have the codec ID included, and nearly all QuickTime codecs have been reverse-engineered already.
What hasn't been reverse-engineered is that "mFactory Animation" codec. mTropolis has an animation format called "mToon" designed for possibly-moving image sequences. The mTropolis demo doesn't allow saving projects, but it does allow creating and saving mToon assets. I guess it would have to, otherwise you couldn't try it out, and it's not like you can do much with an mToon file if you can't save your project, right? (... Right? ... Yeah.)
In the state of the art of the mid-90's, there were basically three ways of compressing animation in a way that could feasibly be played back in real time: Vector quantization, run-length encoding (RLE), or other simple lossless schemes like LZ77. Vector quantization involves taking chunks of the image and converting them into a smaller set of similar chunks (the codebook), and replacing parts of the image with a lookup into the codebook. It's similar to creating a palette for an image (do people even know what that means these days?), except it creates lookups for blocks of pixels instead of single pixels. Run-length encoding just replaces series of identical pixels with a code indicating how long the series is.
How do we poke at this to start guessing what it does? Well, we can pop open Color It!, one of the many programs of the era designed to be an affordable Photoshop replacement, and try doing some things. Let's make an arrow, and give it a weird size like 12x13 so we can find the size easily, then make 2 identical frames so we can determine the frame stride and hopefully match that up with the size somewhere.
Okay, looks like we've got it. Let's set the compression to "None" and export our project and crack it open!
We have a problem though. We told it to be uncompressed, which means we should be seeing something that looks like an arrow shape in the hex data, but we don't. It compressed it anyway. The good news is, we can see from the codec ID and frame headers that this looks like an RLE codec, which is really good news because RLE codecs are way easier to figure out than VQ codecs.
There are a lot of ways to write an RLE codec. You can set a minimum run length to increase the numeric range of runs by adding it to the run count, you can expect that runs and non-run byte sequences alternate, you can let runs go past the end of a row, and so on, but it's very easy to correlate because you can just make test images with runs of given lengths and see how they're encoded.
This did turn out to be slightly more complicated: Most animations have "temporal compression" which allows for frames where runs of pixels are skipped and reused from the previous frame, and later it turned out that there was a special code for vertical displacement, which skips many rows of pixels at once. The 16-bit version is just the 8-bit version, but uses 16-bit values!
Internally, this was handled in a somewhat sneaky way too: ScummVM's mTropolis engine converts the RLE-16 format to RLE-32 so it can decode it on the fly and blast pixels straight into a 32-bit frame buffer... but that's for another time, because...
It looks like we've hit a turning point?
With all of this information, MTDisasm reached a point where it could dump all of Obsidian's data in readable, viewable, and listenable formats. I finally had something resembling the "source code" to the game. That's still a long way from actually running it, but it meant that there was no more information about how it's supposed to work that was out-of-reach.
Upon reaching this point, I still wasn't on the ScummVM team or really looking to join it. I had just come off of porting Glider PRO, which involved re-implementing tons of MacOS stuff by hand, so I really was not shy about spending excessive amounts of my free on this type of thing and doing it myself.
That story is for the next installment though. Next up, I'll take you down the path of turning a mTropolis player re-implementation into reality.
No comments:
Post a Comment