Having actually felt the water from the waist down, I’ve decided to jump out of IFF chunk research, because cracking SimAntics is one of the biggest challenges we face, and that’s the infrastructure behind the entire IFF chunk structure. For the chunk formats that don’t make some sort of meta-reference to SimAntics which we can’t work out because we don’t quite understand SimAntics yet, all we get is say, a list of sound IDs (FWAV), or pie menu text strings, or other bits and pieces of information which, yeah, are important eventually, but serve no purpose and satisfy nobody until we have a client or actual SimAntics disassembler to make use of them.

So the question then is, why don’t we start figuring out SimAntics? Let me explain the situation.

In both games, we have a file called behavior.iff which holds all the text for Edith, the tool used by Maxis to program their objects. This allows behavior.iff to be translated into other languages and is what allowed Jamie Doornbos to give a label for each instruction (See: “92 [STR#] (008B) – Primitives” in TSO’s behavior.iff). In our case, simply knowing the assembly mnemonic of an instruction does not always help us understand precisely what that instruction does, and regardless, we still have to work out the operand syntax based on no documentation by Maxis.

In The Sims 1, you could guess how an instruction works, change one of its operands, boot into the game (which would generally take less than a minute—about 5-10 seconds on computers today) and immediately test your change and see how the game reacts. If you felt you really needed to, you could run the game in a disassembler and eventually find your object loaded in memory and see what the game does with it. In The Sims Online, we are fettered by the fact that we cannot get past the log-in screen. Hope is not completely lost, however. The situation is just extremely bleak.

In The Sims Online’s credits.iff, Jamie Doornbos is credited as the “Simulation Engineer”, with Patrick J. Barrett III and Don Hopkins as “Engineer”s, who we know played a small role in developing Edith alongside Jamie Doornbos. And judging by the fact that TSOSimulatorClientD.dll contains lots of relevant text strings (take for example, “$Me $Object $MasterObjectName $DynamicObjectName $ObjectCreatorName $DialogStrLocal $DynamicStringLocal $Local $Param $Temp $TempXL $NameLocal $TimeLocal $Attribute $MoneyXL $FixedLocal”), we can assume that the entire SimAntics virtual machine was implemented in that one DLL. This DLL exports exactly one function, like all the others: void * GZDllGetGZCOMDirector(void). This function creates, sets up, and returns the pointer to a C++ object, which the game uses to control the virtual machine. We can successfully interact with it, with some code as follows:

HMODULE dllmodule = LoadLibrary("TSOSimulatorClientD.dll");
void * (__stdcall *GZDllGetGZCOMDirector)(void) =
    (void * (__stdcall *)(void)) GetProcAddress(dllmodule, "GZDllGetGZCOMDirector");
void * value = GZDllGetGZCOMDirector();
printf("%p", value);

The object returned to us does not carry with it any variable or method names. We have to figure out what these functions do by looking at their code in x86 assembly. And we have to figure out what they want as input, and what they give us as output. If you’re interested, I have about, oh, zero percent progress documented on the wiki (link). It’s hard, but eventually doable, perhaps.

This is the icon we will be using for the client.

Let’s look at the upside of things. There are only 68 of these darn instructions, and a bunch have got to exactly parallel the ones in The Sims 1. I also just released a tool called iff2html in the repository, which generates a webpage that lets you view the contents of an IFF file. It only works with the STR#-based chunk formats for now, but it works with them all, so it can read both TSO’s and TS1’s behavior.iff files.

So this is why I am saving this mass of stuff for later. Which means I’m on probably everyone’s favorite task: the client. From this point, I am going to implement all functionality in the client up until city rendering. This means I have to prepare an OpenGL windowing library, which will be interesting as I try to mitigate for the fact that all textures need to have dimensions that are powers-of-2.

And I have just set up a Justin.tv account for Niotso. One of these days I plan to broadcast my programming live and talk with people in the comments, so you see what this process actually involves, not what Ghost and Jonathan set out to make you believe.

The large majority of the new HTML5 z-buffer calculator (on the right) was programmed by RHY3756547. I added alpha-blending and went over the geometry again to fix some minor issues.

The game doesn’t use true isometric projection. The camera’s image is actually vertically compressed a little bit so that each tile’s width is exactly twice its height, instead of height*sqrt(3). This allows each tile to have power-of-2 dimensions for easy uploading to the graphics card.

Link to the calculator: http://www.niotso.org/zbuffer/
(Use the arrow keys)

Meanwhile, I’ve been working on IFF reading support. I’ve just made a basic command-line utility, iffexport, to extract all of the chunks from a given IFF file. My next task is to learn all of the chunk formats and document them on Niotso Wiki.

I haven’t started chunk-parsing yet, so at the moment the only screenshots I can offer are catalog thumbnails, which are stored in plain BMP format. See below: