Sorry for the delay. Every couple of years I get the Paper Mario bug and just have to play through the Nintendo 64 title again. They just did so many things right in that game that it's one of my favorites.
Anyhow, I've got the level data partially decoded... it's actually more than it looks, but things like palettes and tile pixel arrangements go on behind the scenes and you can't really see how much work that was just by looking at the pictures. But whatever the case, I can now output images of the levels sans steel blocks, water, special objects et al. This is just the normal terrain.
Behold!
What I've decoded:
The original:
Check out those extra tiles on the top and bottom. Intriguing, no? It's always fun to hack levels in video games and see just how much unnecessary garbage there is in the level data that's usually leftovers from level creation. Lemmings 2 is certainly no exception. See all those blocks making up the floor and walls? In the final version of the level, those are steel blocks. Yeah. So them being there is just taking up file space, as the level would play just the same without them.
Take special notice of the few blocks jutting out the top, because they're there for a
reeeeeeeally interesting reason. Notice how they graphically connect to the pixels below them? The level designers had pre-set blocks and said "I want a vertical block right about there, going off the top of the screen." The upper part of the vertical block is still stored in memory, though.
Now get this...
The levels, much to my surprise, are not built of these pre-set blocks. They are explicitly defined on a per-tile (in this case, 16x8 pixel) basis. ALL the extra tiles that you'd never see can easilly be removed to allow the data to be compressed more.
Having said that, we seem to be very fotunate in this case. Turns out the developers left those pre-set blocks in the game for us to use! They're completely unnecessary for the program to function, and indeed only waste file space in the end, but they're defined in the STYLES directory and we'll be able to use them in our own levels without doing the work to reconstruct them ourselves.
With those pre-set block definitions, I'll be able to make the editor run a pass through the decoded level data and match up applicable tile combinations with the presets to make level editing MUCH easier. As it is, it's just a grid of 16x8 tiles, and that's not easy to edit at all. If I can do the math backwards and turn those tiles back into block presets, we can move them around just like the level designers did when making the levels in the first place.
This is a rather exciting turn of events that I wasn't expecting, but I am very much interested in making it work. Oh yes, and rest assured that when the editor I make outputs level data to file, it will remove extra tile information that isn't needed. (-: