M1 compatibility

From AlephWiki

Marathon 1 Compatibility with Aleph One

Return to History

Loren Petrich, November 8, 2000

In this article, I will discuss what ought to be done for making Marathon 1 and M1 scenarios A1-compatible. I believe that this compatibility ought to be achieved without making great changes in the A1 app; this means that M1 data files will have to be converted into more A1-friendly formats. However, this approach has the advantage that M1 compatibility can be achieved with a minimum of changes to the A1 app itself, meaning that it can be developed in parallel.

Furthermore, the necessary conversion ought to be done in as automated a fashion as possible, so that the only work that really needs to be done is writing the conversion software. Ideally, one ought to be able to have a conversion app that requests the data files to work with and generates a set of A1-compatible data files. This app will be able to work on not only Marathon 1 itself, but also M1 scenarios such as "Trojan". However, I believe that creating such an app is feasible; my discussion below will get into the details of such an app. And such an app will also get around copyright problems, since one will not need to distribute any converted data files.

Let us now turn to the details of such a converter.

The most obvious thing that will need to be converted is, of course, the map files. These are broadly similar in format for M1 and A1; however, there are some differences that will have to be accounted for.

Polygons have fewer data members in M1 than in A1; there are no background sounds, for example. Such missing fields can be set to appropriate "empty" values.

Sides do not have built-in lighting; their lighting is apparently taken from nearby floors. My Marathon Map Viewer contains a guess as to how the sides are illuminated.

Platform-polygon heights are somewhat screwy in M1; again, my Map Viewer contains a guess as to how to fix them.

Marathon 1 platform definitions (what sounds, etc.) could be reverse-engineered and used to create an M1-compatibility MML file.

Terminal texts do not reside in the map file but in the app file; the converter could simply take them out of the app file and create appropriate prepared forms in the map file. Also necessary to do is map terminal ID's in the sides from resource ID's to indexes into the TERM chunks.

Wall and control-panel texture assignments are significantly different; A1 will have to be changed to load a control-panel texture as well as a wall texture and a scenery texture for each level; however, such preloading can be controlled with appropriate MML. Likewise, loading of landscape textures can also be suppressed with appropriately-set-up MML. And MML access to the control-panel definitions is already set up.

Lights are different from M1 to A1; however, a converter for lights should not be too difficult to write.

Finally, there is the question of polygon attributes. These differ significantly from M1 to A1, with M1 having "Glue", "SuperGlue", and dangerous floors (how lava and PfhorSlime are implemented). The Glue and SuperGlue might be imitated by some A1 polygon attributes, but the dangerous liquids are more difficult. A1 may have to be modified to implement those.

The other data files are somewhat simpler problems. I have already written a M1->A1 shapes-file converter, and soundfile conversion seems fairly trivial, with the main problem being the proper mapping from M1 resource ID to A1 index in the file. Physics conversion may be more difficult, but judging from the code comments, there are not likely to be big physics-format changes from M1 to A1.

As to the music, all I know is that the M1 music file is some sort of archive with MIDI files in it.

There are certainly some other loose ends here and there, but I think that this covers it.

Part 2

Checklist for Original Marathon to Aleph One Converter:

Convert soundfile. Create a list of sound-resource ID's in order, using only the base ones. (nnn0, not nnn1 or nnn2). This will be for converting the resource ID into an index into the A1 soundfile. [Work is starting on that]

Convert shapes file. Be sure to convert sound resource ID's. Also, one will need to copy in the Moo "Interface" chunk, since the M1 and A1 HUD's are significantly different in construction. [Converter exists for shapes file; however, it does not add the Moo interface or convert sound ID's]

Convert physics file. Be sure to convert sound resource ID's.

Create Marathon Markup Language compatibility files. Be sure to convert sound resource ID's; create two such files, one for M1 in general, and one for M1 sounds, since the former will be fixed and the latter will vary. Unless someone had created a M1 version of Fux! :-) Specific areas to cover:

Loading of M1 wall textures; no loading of landscape textures -- need modification of A1 code.

Definitions of items; map repair chip onto uplink chip (make it possible to hold more than one of them), alien recharger onto S'pht card.

Definitions of control panels; there is an extra kind of M1 switch that appears in "Defend THIS!" and "Couch Fishing" that will eat repair chips if they are present, but can still be toggled otherwise. May have to define a special type of switch behavior for that and modify A1 to support that.

Definitions of scenery.

Definitions of platforms.

Convert map file.

Add extra attributes, such as "NONE" liquid and sounds to polygons.

Sides apparently inherit floor lighting.

Convert light-data chunks from M1-style to A1-style.

Bump up the attribute ID's of M1-specific polygon attributes, like "injury" and "glue"; modify A1 to support these attributes.

Get terminal data from M1 app and create appropriate "TERM" chunks with it. Also, get Marathon logo to use as signon/signoff.

Created integrated app for doing this conversion; should read and write all the necessary files without further intervention.

MacOS version

Cross-platform version