SEGA Master System level modifying

[ccexplore]

Out of interest, if you cleared the whole space of default levels and just used it for new levels, how much space would be available, and approximately how many levels would fit in that?

At a rough guess, the levels take up just under 72KB.

How much space is left at the end of the ROM (presumably where you're currently sticking the injected level)?

Actually, from browsing technical docs on smspower, SMS supports largest ROM size of 512 KB, while the Lemmings ROM is apparently only 256 KB.  So can we simply expand the ROM size to 512 KB, and then we're left with tons of space for maps?

It also sounds like you have a pretty good handle on the level format and other things in SMS Lemmings, perhaps it should be documented to benefit others who may want to further create tools for custom levels and/or tilesets?

As it turns out, so far from just reading your source code, I've been able to work out a lot of things myself, so I guess it's enough to just document things that aren't captured in your tools and programs.

[ccexplore]

That's very close to the intended solution, but it is still a backroute as it takes out the best trick of the level.
This should fix it.

I very distinctly remember playing DOS version of this level, but have totally forgotten the solution by now and pretty much re-solve it from scratch (which took a bit of work, so nice puzzle!).  I think you can solve it without using every single skill though, so I don't know if this is the right solution or not (attached zipped screenshot).

[Clam]

Following a little persuasion, I've decided to join in the fun and convert one of my own levels. This is "Play Bridge" from my 05 pack. Thanks Pooty for making the converter, it's already quite a usable setup

I tried one of my earlier levels first ("Hello, Goodbye"), but I ran into some difficulty - putting crystals together from little tiles is a real mission, and there doesn't seem to be a tile that connects crystals to the pipe terrain. Just a disadvantage of having a fixed set of square tiles, it seems - certain terrain configurations just aren't possible. This really bugged me about L2 as well . On that note, IIRC L2 had a set of predefined terrain structures - does SMS have these as well, or do they need to be built from scratch?

[ccexplore]

On that note, IIRC L2 had a set of predefined terrain structures - does SMS have these as well, or do they need to be built from scratch?

I guess it's up to Pooty to see if he can find such data in the ROM, but I'm leaning towards no.  For obvious reasons, it's much more likely for activities like level editing and graphics design to be done on an actual computer and then at the end the finished results incorporated into the ROM, rather than actually creating an editor that runs on the console itself.  So any data in the ROM would have to be explicitly selected to be copied from computer to ROM.  Plus back in the days ROM space would be somewhat at a premium.  So the bottom line is, while conceivable, it seems unlikely that they would include into the ROM the extra data that defines terrain structures from tiles, seeing as they have no role in the actual game.

No that I'm sure it'd help you much even if it exists.  I know the Mappy editor supports creating "brushes" from combinations of tiles, but I haven't used it enough to know whether it supports saving/loading "brush sets", or whether the file format for such things (if exist) is documented or not (so that one can convert whatever ROM data that defines terrain structures into the "brush" format consumable by Mappy).

Ignoring that important point, it may be possible however to build up a set of terrain structures through statistical means, analyzing the in-game maps to come up with good candidates for terrain structures, and then hand-refine them into a usable set.

[namida]

That's very close to the intended solution, but it is still a backroute as it takes out the best trick of the level.
This should fix it.

I very distinctly remember playing DOS version of this level, but have totally forgotten the solution by now and pretty much re-solve it from scratch (which took a bit of work, so nice puzzle!).  I think you can solve it without using every single skill though, so I don't know if this is the right solution or not (attached zipped screenshot).

From what I can tell of that shot, I'm pretty sure it's the right one.
You are correct about not needing every skill - the floater has no use.

[Pooty]

How much space is left at the end of the ROM (presumably where you're currently sticking the injected level)?

Actually, from browsing technical docs on smspower, SMS supports largest ROM size of 512 KB, while the Lemmings ROM is apparently only 256 KB.  So can we simply expand the ROM size to 512 KB, and then we're left with tons of space for maps?

There is just under 4KB (4064 bytes) beginning from $3B020. Actually, the zeroes at that part of the ROM begin at $3B01B, but I'm not sure if those zeroes are being used for anything. I don't think they do, but I didn't want to risk it.

And I also thought about expanding the ROM size. It can be done, and certainly works on emulators. Not sure about on real Master Systems, but I don't see why it won't, as long as the data is written into a 4 megabit cartridge with a suitable mapper.

SMSPower is an amazing website. I couldn't have done a lot of this stuff without it.

I've attached the automated disassembly of the game, but I've blanked out page 04, which only contains maps. This removes all grass-style levels (except "Hunt the Nessy" and "One Way or Another"), "Lend a Helping Hand", "The Ascending Pillar Scenario", "Tailor-made for Blockers", "Call In the Bomb Squad" and "Now Use Miners and Climbers". If you need this data, you can yoink it straight from the ROM. The data begins from $10000 - $13FFF, and save this data to Lemmings.dat.40. The downloads you need and the instructions to set up the assembly of the game are at http://www.smspower.org/maxim/HowToProgram/DownloadingStuff.

On that note, IIRC L2 had a set of predefined terrain structures - does SMS have these as well, or do they need to be built from scratch?

There isn't, unfortunately. I'm certain that the level designers had such data on them, but it's not in the ROM. All we have are the tiles. Although now you mention it, a possible future project may be to make Lemmings 2: The Tribes tilesets work on this game. The colours would almost certainly have to be modified, mind you. The Master System can only render 64 different colours. But I'm getting a bit too far ahead of myself with that suggestion.

[ccexplore]

Although now you mention it, a possible future project may be to make Lemmings 2: The Tribes tilesets work on this game. The colours would almost certainly have to be modified, mind you. The Master System can only render 64 different colours. But I'm getting a bit too far ahead of myself with that suggestion.

Interesting idea. Although I'm thinking it might be also be interesting to go the opposite direction, porting the Sega tilesets (especially the SEGA one) over to Lemmings 2 (taking advantage of more skills and more traps in that game).  But again, as you said, way ahead of ourselves.

When the time comes, I can help with color reduction algorithms if needed.  Does SMS use a fixed set of 64 colors, or a palette of 64 colors selectable out of a much larger color space?  For comparison, Lemmings 2 uses a 256-color-palette graphics mode out of an 18-bit color space, although looking at its tilesets, I kinda think each don't even necessarily use up all 256 palette entries.  64 may well be enough.

I think actually the number of tiles in Lemmings 2 tilesets might be more problematic.  I don't remember anything concrete off top of my head, but I have a feeling the tilesets in Lemmings 2 probably use up more tiles than what you can fit into a Sega tileset.

[Pooty]

The Master System has two active palettes of 16 colours, for a total of up to 32 colours. The first palette is used for background tiles only. The second palette can be used for both background tiles and sprites.

The colours available is from a selection of 64 6-bit colours, meaning there are four shades of red, green and blue (0, 85, 170, 255).

Lemmings uses the same set of colours throughout the game, and is duplicated between both palettes. I think this is done because of the way the game draws more than 8 lemmings on the same scanline by pasting the lemming sprites into the background. That said, it isn't really necessary to duplicate the entire palette. I've attached an image of the palette used by the game, and identified eight colours that are used by the lemmings (marked with red circles), and would therefore need to be identical in both palettes. The two shades of grey are only really used during the splatting animation (as well as the cursor), so they could be edited to free those colours.

The colours I marked with green pluses are only used in maps, and they could be edited. The orange colour is a duplicate, and the black colour is the solid black that lemmings can stand on.

The remaining colours are used as part of the trapdoor.

[ccexplore]

I see.  So the color space itself is only 64 colors (I should've known, we're talking about the SMS silly me ).  This definitely will make automated porting of colors from Lemmings 2 over to SMS a little tricky, especially with sets like Shadow where everything are just shades of dark blue .

Anyway, on better news, I believe I've figured out trap modification, or enough of it for Pooty to start experiment supporting traps in custom levels.

The $DB97 value is actually an array index into a table that actually specifies the trap modification.  This array starts at $3B1B (under 0-based indexing) with each element being 4 bytes.  As you noted, 0 for $DB97 is treated special as "no trap modifications".  A $DB97 value of for example 3 would therefore refer to the 4 bytes starting from $3B1B + 3*4 = $3B27.  The $DB97 must be between 1-8 since right after the 8th entry of the array are more code, so there's only room for 8 entries.

The 4 bytes within an entry break down as follows:
  byte 0: which type of trap. Must be 1-4 (all other values ignored by game programming):
        1=squish (ie. Fun17)
        2=noose (ie. Fun15)
        3=beartrap (ie. Fun21)
        4=the trap in the various Sega levels
  byte 1,2: little-endian WORD specifying x-position (in pixels) of trap trigger location
  byte 3: specifying y-position (in pixels) of trap trigger location

I haven't drilled deeply into the code the game does for detecting whether a lemming hits a trap trigger or not, but based on preliminary reading, I think the trap trigger is always 4x1 pixels, ranging from (trapx, trapy) to (trapx+3,trapy).  It's easiest to see the relation by simply looking at the original values in the table, and see what location it corresponds to in the tilemap for the level.  Below is the $3B1B table in the unmodified ROM:

Code: [Select]

$3B1B: 0, 0000, 0,  (not used: 0 in $DB97 causes all the trap-related code to be skipped)
       2, 02EC, 88,  (Fun15/Taxing1)
       1, 0160, 88,  (Fun17/Taxing6)
       3, 02A0, 80,  (Fun21/Mayhem26)
       4, 00CC, 80,  (Fun20/Mayhem9)
       4, 0224, 80,  (Fun26/Mayhem12)
       3, 02D0, 38,  (Taxing2)
       4, 0334, 70,  (Tricky25/Mayhem13)
       4, 0034, 60,  (Tricky21/Mayhem18)
In case it isn't clear, the Sega programming's support for traps is extremely limited:
  1) at most one triggered trap in the level.
  2) it only has programming to explicitly support 4 different types of traps, namely the ones listed above.

So at this point (and likely well into the near future), please don't ask for changes to remove these limitations, as it will require major code surgery.

[ccexplore]

I should note that I haven't yet figured out where the game actually stores the tiles for the animation frames of the traps.  But given that the game only supports 4 types of traps anyway, you might as well just use an emulator and screen capture to capture the necessary graphics (especially since we really only need one frame for use in level editing).  I'm not sure, but it looks like the game uses a specific set of tiles in the tilemap for the tiles of a trap, so maybe Pooty can just modify the tilemap PNG files to incorporate the actual graphics for one frame of the trap (so it shows up correctly in Mappy), and then have his program recognize the usage of these specific tiles as a way to determine where the trap is located, and therefore how to modify the 3B1B table correctly to make the trap work.

[Pooty]

Ah-ha! Thanks for that.

And.. err.. darn. That's going to complicate trap implementation a bit, since all but one trap (Taxing 2) is used in a repeated level. Unless you overwrite Taxing 2 and use the 6th trap entry, there's no way you can get away with placing a trap in your level without affecting the rest of the game. For one-shot levels like we're using at the moment, that's not a problem, but I'm not exactly a fan of destroying games.

As for the location of the trap frames, they're stored uncompressed from $343C6 (page D, in-game offset $83C6). You'll also find other animated features, such as the home fires, waters, and an unused one-way wall animation, which is unimplementable. There's also some unused frames in there, which is an unfortunate waste of ROM.

The trap frame pointers are stored in little-endian from $3CB4, and they are stored in order. Again, they can point to the unused trap frames. However, the dripping tap trap's default frame points to the same one as the bear trap's ("F", $8C in the disassembly, which should read $46, $8C), since they are both completely blank.

[ccexplore]

And.. err.. darn. That's going to complicate trap implementation a bit, since all but one trap (Taxing 2) is used in a repeated level. Unless you overwrite Taxing 2 and use the 6th trap entry, there's no way you can get away with placing a trap in your level without affecting the rest of the game. For one-shot levels like we're using at the moment, that's not a problem, but I'm not exactly a fan of destroying games.

I think I may have a way that lets you use the unused $3B1B slot (0th entry).  That slot normally isn't used because the game treats a 0 in $DB97 specially.  But, due to the exact way they calculate the array indexing, it looks like a value of 64 (decimal, or $40 hex) for $DB97 will end up wrapping back to the $3B1B address, but unlike 0 will not cause the game to disable traps.

Making use of this extra slot, plus some additional hacking of the $DB97-writing code, would then allow you to pick any of the 15 existing trap-enabled levels to be replaced with your custom level, without affecting any other levels (including the repeat of the level you replaced, if any), instead of Taxing 2 being your only "safe" replacement option.

Of course, this still isn't really a good long term solution for when you want to potentially support any number of the 120 levels being trap-enabled.  Unfortunately that sort of change would require a little more code surgery like anything else significant with traps.

[Pooty]

Sounds good to me. And with that, I think I may have enough information to implement a trap in a custom level without damaging the rest of the game. There's only one way to find out.

[Edit] Damn. Good feeling's gone. I'm not sure about how to change the subroutine beginning from $1F0C to get the trap implemented in the custom level. I think I need to plan this out better.

[Edit 2] Hold that thought. I might be able to get somewhere if I attack the subroutine call at $3EC5.

[Adam]

Great stuff! I'm in awe at how much you two have been able to do in such a short space of time.

This could just be me being stupid, but I can't recall seeing the trap on the seventh row down in your image.. it looks like it fits in the Ice style, but I'm probably wrong!

[Pooty]

That's actually the tap trap in the SEGA levels. That said, the ice levels really could do with a trap. An animation of a lemming getting zapped would be a start.