Original Lemmings Graphics

[CanardSauvage]

Hey,

im currently playing around with Silverlight and Lemmings and I would like to use the original Lemmings Graphics. I found the description of the dat-file format with google and how the levels are stored. But I cant find anything about how to extract the bitmaps from the vgagr0.dat with the ground0O.dat. Can anyone help me with some documentation? Thanks!

[Simon]

Hi,

I wasn't able to find it on the net either. ccexplore wrote the documentation you need, and Mindless was hosting it. Maybe one of them will reply shortly.

I've implemented reading L1 graphic sets in C++ with Allegro 4. It's part of the Lix game code. In case you get stuck when reading the docs, it can be viewed at https://github.com/SimonN/Lix/tree/master/src/level, the relevant files are crunch.h, crunch.cpp for the encryption format, and graset_1.h, graset_1.cpp for extracting the graphics from the de-crunched data.

Hint about bitmap storing in vgagrX.dat:

If you get the documentation, you might also take note of the following hint, which the documentation doesn't have: 4-bit bitmaps (16 colors) are stored component-wise. There are 4 monochrome bitmaps for one 16-color bitmap. First a monochrome bitmap that describes the first bit of each pixel, then another monochrome bitmap which describes all second bits, etc. These single-bit bitmaps are stored in little endian order, i.e. the first bitmap adds 1 to each color, the second 2, then 4, then 8.

-- Simon

[geoo]

Mindless' site with the docs is currently available at http://www6.camanis.net.ipv4.sixxs.org/lemmings/tools.php

[CanardSauvage]

Thank you both, that really helped!

[Simon]

We were talking a lot about the data format on IRC recently. The L1 vgagrX.dat/groundXo.dat format description at  Mindless's site seems to have a mistake: The terrain is actually stored in the first data section of vgagrX.dat, and the special objects are stored in the second section. The format description claims it's the other way around.

If ccexplore gets to update this, he might also take note of the hint about bitmap storing from my first reply to this topic.

A third thing he might add is the transparency/opacity coding for the masks. A 1 stands for a solid pixel, a 0 means transparent background. The format description says that he forgot it at the time of writing, and people should experiment.

There's another curiosity we found. The 16-color bitmaps for the terrain only make use of the graphic-set-specific 8 colors, numbered 8 through 15. The bitmaps are stored in 4 planes, and the plane order is little endian, i.e. the plane that adds 8 to the color comes last. Since the terrain uses a color >= 8 for each solid pixel and color 0 (black) for air, the last plane is equal to the mask plane. If you actually look at the terrain metadata in groundX.dat, you will see that the mask location is actually the last plane. (E.g. the crystal set's terrain piece 0 has a size of 0x20 times 0x20, which means its 4-bit bitmap (two pixels per byte) requires 0x400 / 2 = 0x200 bytes of storage, but the mask location starts only 0x180 behind the image location's begin.)

I don't know what L1 itself does with this data. It may read a 16-bit bitmap and then re-use the last plane for the mask, or it may just read the first three planes, add 8 to everything, then cut via the mask. I believe it does the former, since it must read four-plane bitmaps anyway when making the special objects; they use all 16 colors.

-- Simon

[ccexplore]

If you actually look at the terrain metadata in groundX.dat, you will see that the mask location is actually the last plane. (E.g. the crystal set's terrain piece 0 has a size of 0x20 times 0x20, which means its 4-bit bitmap (two pixels per byte) requires 0x400 / 2 = 0x200 bytes of storage, but the mask location starts only 0x180 behind the image location's begin.)

I seem to recall that when Eric made Lemmix, he ran into a similar initial observation and was wondering whether the mask location can be ignored, but then he later found in a few other terrain pieces that the mask location is not equal to the last plane.  I'll see if I can dig up the email or not.  I have no idea at this point whether if you modify the data you can make the game use all 16 colors for terrain (and have the mask be independent of the 4 color planes), or whether it's still the case that either the 4th color plane or the mask is actually redundant and not used.

[Mindless]

I finally got around to asking Simon for patches to the DAT and VGAGRx docs, so the copies on my site now have the corrections mentioned above.