Old Mac files have two independant halves: the data and the resource fork. The resource fork is a sort of compartmentalized treasure map that's bolted onto most old Mac files. It provides a standard way of holding standard structures (like colour palettes, dialogs, machine code) and also for referencing information packed in the data part of the file.

This actually makes the data part of the file quite underused, as it's easier to keep most things in the resource fork. (The Lemmings executable, for instance, is just one large resource fork). Which, unfortunately, is a bit of a pain, as by default the resource fork is sheared off on a non-Apple filesystem.

Thankfully by packing the Mac files into a data-only format (in my case, BinHex .HQX files), it is possible to read both the data and resource fork on any platform. Of course, the resource fork is only read by the Apple system libraries and developer tools like ResEdit, so it doesn't look very nice as one long string.

Right now my tool just converts the above gibberish string into a more human-readable data structure. So it's only really useful if you're extracting data or poking around for information.

The executable has a little bit of useful information (such as the single colour palette used by Lemmings), however the Graphics file is much more cryptic. All the resource fork contains is a single table of 12-byte tuples, flagged with interesting names like "Psygnosis0", "Logo0", "Grounds1", "Special2" etc. I think the first 4 bytes references an offset, second 4 bytes references a length (all referring to the large data part of the file), but I have no idea what the last 4 bytes represent. Presumably it is an amount, as the highest two bytes always represent a small number, but it doesn't steadily increase/decrease down the list and it's always larger than the image size. As for the graphics data itself, all I know so far is that there is the occasional raw palette index, making it possible to identify sections of the image in a paint-by-numbersish way.

If anyone out there is mad enough to try it, you don't even need a real Mac to check out Lemmings with ResEdit (Basilisk II, a starter kit and a copy of HFV Explorer will do the trick).

Aha. Cheers for the info. Method 2 seemed the simpler one in principle, I just felt that writing a specific method to blit objects behind was somehow sacriligeous (needing four blits instead of one! FOUR!).

I wish I knew how to do proper masking. Pygame doesn't seem to have anything in the documentation mentioning a right or wrong way (not sure how it was originally done, but my subtractive terrain handling takes unfair advantage of how an RGBA canvas can also have a transparent colourkey)

I'll say bon voyage to the two canvas system, which was at best slightly hackish. Hopefully the new method won't be too burdensome on the CPU :undecided:

Actually, even DOS Lemmings is sophisticated enough not to use the PC speaker even for sound effects (it uses Adlib FM Synthesis).

DOS Lemmings does support outputting PC speaker sound effects when it cannot find an Adlib/Sound Blaster card (easy to replicate, starting Lemmings in DOSBox at well above 2000 cycles will make the program fail to autodetect the Sound Blaster, forcing it to revert to the PC speaker for sound effects).

Tried to run under Linux (Ubuntu Dapper). Case-sensitive file/directories are somewhat ignored, so none of the levels will convert from LVL to INI if your export directory contains a capital letter. (interestingly, the graphics still convert without a hitch)

After picking a path that's entirely lowercase, the conversion process works fine for a while, but keels over when trying to patch the first level ("CRC of source differs from that in patch header"). One guess is that during the LVL2INI conversion process, the file I/O methods in UNIX Java translate "\n" into just a linefeed character (i.e. the civilized way), whereas under Windows Java it may instead give a carriage-return + linefeed (2 characters, a nasty relic from DOS and the norm for Windows text editing).

If this were the case it would certainly throw off the binary diff. Of course this is all guesswork, I haven't got a working Windows machine to litmus-test the theory on. Just for fun, here's my extracted copy of lvl1000.ini:
# LVL extracted by Lemmini # lvl1000.lvl
releaseRate = 1
numLemmings = 80
numToRecue = 80
timeLimit = 3
numClimbers = 0
numFloaters = 0
numBombers = 0
numBlockers = 0
numBuilders = 12
numBashers = 0
numMiners = 0
numDiggers = 0
xPos = 1216
style = brick

# Objects
# id, xpos, ypos, paint mode (), upside down (0,1)
# paint modes: 8=VIS_ON_TERRAIN, 4=NO_OVERWRITE, 0=FULL (only one value possible)
object_0 = 1, 1344, 128, 4, 0
object_1 = 1, 1408, 64, 4, 0
object_2 = 1, 1472, 0, 4, 0
object_3 = 0, 1376, 232, 4, 0
object_4 = 9, 1376, 264, 4, 0

# Terrain
# id, xpos, ypos, modifier
# modifier: 8=NO_OVERWRITE, 4=UPSIDE_DOWN, 2=REMOVE (combining allowed, 0=FULL)
terrain_0 = 24, 1376, 198, 0
terrain_1 = 24, 1440, 198, 0
terrain_2 = 24, 1436, 128, 0
terrain_3 = 24, 1500, 128, 0
terrain_4 = 24, 1500, 64, 0
terrain_5 = 24, 1564, 64, 0
terrain_6 = 31, 1508, 262, 0
terrain_7 = 31, 1568, 198, 0
terrain_8 = 31, 1632, 124, 0
terrain_9 = 30, 1508, 278, 0
terrain_10 = 30, 1508, 310, 0
terrain_11 = 30, 1568, 214, 0
terrain_12 = 30, 1568, 246, 0
terrain_13 = 30, 1568, 278, 0
terrain_14 = 30, 1568, 310, 0
terrain_15 = 30, 1632, 140, 0
terrain_16 = 30, 1632, 172, 0
terrain_17 = 30, 1632, 204, 0
terrain_18 = 30, 1632, 236, 0
terrain_19 = 30, 1632, 268, 0
terrain_20 = 30, 1632, 300, 0
terrain_21 = 30, 1696, 288, 0
terrain_22 = 30, 1696, 256, 0
terrain_23 = 30, 1696, 224, 0
terrain_24 = 30, 1696, 192, 0
terrain_25 = 30, 1696, 160, 0
terrain_26 = 30, 1696, 128, 0
terrain_27 = 30, 1696, 96, 0
terrain_28 = 30, 1696, 64, 0
terrain_29 = 30, 1696, 32, 0
terrain_30 = 30, 1696, 0, 0
terrain_31 = 2, 1432, 302, 0
terrain_32 = 2, 1368, 302, 0
terrain_33 = 2, 1304, 302, 0
terrain_34 = 19, 1714, 0, 4
terrain_35 = 19, 1778, 0, 4
terrain_36 = 20, 1834, -8, 4
terrain_37 = 20, 1834, 8, 4
terrain_38 = 20, 1850, -8, 4
terrain_39 = 19, 1714, 288, 8
terrain_40 = 19, 1778, 288, 8
terrain_41 = 20, 1834, 302, 8
terrain_42 = 20, 1834, 286, 8
terrain_43 = 20, 1850, 302, 8
terrain_44 = 19, 1240, 288, 8
terrain_45 = 19, 1208, 288, 8
terrain_46 = 19, 1208, 0, 12
terrain_47 = 19, 1272, 0, 12
terrain_48 = 19, 1336, 0, 12
terrain_49 = 19, 1368, 0, 4
terrain_50 = 20, 1424, 8, 4
terrain_51 = 20, 1440, -8, 4
terrain_52 = 20, 1424, -8, 4
terrain_53 = 20, 1296, 286, 0
terrain_54 = 20, 1312, 302, 0
terrain_55 = 20, 1296, 302, 0
terrain_56 = 42, 1216, 0, 0
terrain_57 = 42, 1248, 0, 0
terrain_58 = 35, 1234, 32, 0
terrain_59 = 42, 1250, 160, 0
terrain_60 = 42, 1218, 160, 0
terrain_61 = 42, 1232, 192, 0
terrain_62 = 42, 1752, 288, 0
terrain_63 = 42, 1784, 288, 0
terrain_64 = 35, 1768, 160, 0
terrain_65 = 42, 1752, 128, 0
terrain_66 = 42, 1784, 128, 0
terrain_67 = 42, 1766, 96, 0
terrain_68 = 20, 1200, 286, 0
terrain_69 = 20, 1200, 302, 0
terrain_70 = 20, 1200, 8, 12
terrain_71 = 20, 1198, -6, 12

#Steel
# id, xpos, ypos, width, height

#Name
name =  It's all a matter of timing

Could you elaborate on this a bit? I'm not sure what it is you're trying to do. XML?

Ooh-er, could've explained myself better there At some point, I'm going to have a shot at making an open-source extendable Lemmings clone. It'll be done in C and SDL, which means (hopefully) that porting and drop-in improvements should be trivial. I'm developing this on a gcc/linux base, which should compile under Windows with mingw32. No idea if VS6/VS.NET/Microsoft Magic Mystery Compiler will touch it however ;/

The Pingus guys have done a great job, however I'm aiming toward something more lightweight and ultra-portable. Oh, and ClanLib is waaay too large to stick onto a PDA. Heaven help you if you change versions :/

To start with, I'm just trying to make the game data manageable. So all the terrain/animations will be converted to indexed PNG, and the level information converted to XML documents. XML is nice because both people and computers can read it

Each level will be stored in an XML file, and there should be some mechanism which refreshes the index (containing all the levels/different games) each time you run the program. For example, if you were to develop a level called "Taste the golden spray", and you want it positioned as Level 12 of Fun on a levelset called "My Generic Custom Game", you could add this XML to the appropriate file:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Games available are Classic, ONML, Your_game_name_here -->
<LemLevel game="My Generic Custom Game" difficulty="1" level="12">
 <title>Taste the golden spray!</title>
 <settings levelset="2" release="80" save="80" speed="20" time="180"/>
 <skills climber="0" floater="0" bomber="0" blocker="0" builder="0" basher="0" miner="0" digger="0"/>

 <!-- BEGIN level metadata -->
 <Interactives>
   <interactive piecenum="4" xoffset="0" yoffset="0" flag_ground="0" flag_nooverdraw="0" flag_upsidedown="1" />
   ...
 </Interactives>
 <Terrains>
   <terrain piecenum="12" xoffset="0" yoffset="0" flag_black="1" flag_nooverdraw="0" flag_upsidedown="0" />
   ...
 </Terrains>
 <Steels>
   <steel xoffset="0" yoffset="0" xwidth="16" ywidth="16" />
   ...
 </Steels>
</LemLevel>

It's very preliminary at the moment, any suggestions are more than welcome.  There's a good chance that the schema will be extended at some point to include a broader definition of interactive objects (think the player-controlled cannons in Lemmings 2).

You can skip this step if you want, I already have working C++ code for compression and decompression.  (But I hope you will credit me for it if you do decide to use it.)  E-mail me for more info.

Thanks greatly for the offer, however I'd feel more confident if all the code is pure C. But then again, I haven't had time to compile test my attempt yet, so I may come crying back