SEGA Master System level modifying

[Adam]

Indeed, it would.. I'm crap at drawing things from scratch, but I'm sure it could be possible to attempt to find one from another port and modify it to the SMS' specs.

[Pooty]

Good news. The traps are working now. I just need to update the tilesets to clearly indicate the trapped tiles, and then I can release it. I'm going to try and get it done within the hour. So you can expect it in two hours.

[Adam]

Good news. The traps are working now. I just need to update the tilesets to clearly indicate the trapped tiles, and then I can release it. I'm going to try and get it done within the hour. So you can expect it in two hours.

Okay, so that's three hours?

Seriously.. great work, Pooty!

[Adam]

Okay, an ONML level here - Havoc 9 - AAAAAARRRRRRGGGGGGHHHHHH!!!!!!.

Changed the skills and time here to make the level harder, but it is still possible to pass the level.

[Pooty]

...and it's done! Not ARRRRGGGHHH!! I'll check it out in a minute.

Traps are now available, downloadable in the opening post of this thread. I've attached an image to show how you're supposed to lay them out in Mappy. The highlighted tile is the one you use to feed the co-ordinates into leveldata.txt. Note the co-ordinates it lies on, and type them in.

Setting the <Trap Type> to 0 prevents the implementation of traps. This has the added benefit of fixing that glitch that made holes in your level if there was a trap in that level in the original game.

One other thing. The co-ordinates you feed it are tile co-ordinates by default. You can override this so you can provide it with pixel co-ordinates instead by using the x,y prefixes. So if you want to place your trap trigger at the pixel location 256, 64 in your level, you enter...

Code: [Select]

<Trap X> x256
<Trap Y> y64

[Adam]

Traps work brilliantly, thanks Pooty! Gonna try and add a couple of traps into levels where they need them.. leave it with me!

[ccexplore]

[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.

I see.  So where did you find the space to fit your new code in?

I just took a brief look at the $1F0C routine, and I know how you can rewrite that whole thing to it smaller, so that you could fit one more set of instructions for the custom level.   But I guess it's even better anyway if you can already find extra space somewhere else to insert the extra instructions.  Good job!

[Pooty]

I'm using the free space between $7670 and $7A7F as if it were a coding sandbox, since it's guaranteed to be accessible at all times. That space is only being used for two things at the moment: the trap subroutine I just implemented, and the custom level's map data (although I've since realised I could have used the empty space at $716F - $7173 for that purpose).

[ccexplore]

It looks like there's a bug in your calculation for the trap implementation in your converter, at least based on the included source code (Level Data\traps.h):

Code: [Select]

    //Writing the most significant bit in the little-endian value.
    if (trapX > 256)
    {
        if (trapX > 512) romData[offset++] = (unsigned char) 2; else romData[offset++] = (unsigned char) 1;
    }
    else
    {
        romData[offset++] = (unsigned char) 0;
    }
But given the map area's width, trapX can get up to $37F, so the most significant byte can range from 0-3 rather than 0-2 as in your code.

You can actually get the most significant byte much more easily by using either the right-shift operator >> or just a division, ie.:

romData[offset++] = (unsigned char)(trapX >> 8);   or
romData[offset++] = (unsigned char)(trapX / 256);

[Pooty]

Balls! How did I manage that? I must have done something stupid when working out the maximum X co-ordinate. I'll fix that right away.

[Edit] Fixed using the bit shift method because... I love bit shifts.

[ccexplore]

If there are 3 lemmings, on the other hand, setting the value to 33 means you'll only rescue 99% if all lemmings are rescued. I'd like to fix that somehow. Three ideas spring to mind; either by removing any mention of percentages and replacing it with units (e.g. Number of Lemmings 20, 19 to be saved), by implementing a lookup table, or by implementing a division subroutine, active when each lemming is rescued.

Since most people don't mind showing number of lemmings instead of percentage, I'll definitely put my vote on doing that, because it is most definitely the simplest way to fix the problem.  You see, all you'd have to do is basically to replace the graphics for the "%" with a blank and you're almost done!  This game doesn't even bother with any special messages if you do get 100% or any other "special" % values, you basically just get a "rock bottom" message, a "try harder" message (if you reach at least half of the goal), and then no congratulatory messages (!) if you meet or exceed the goal.

With this approach, you basically set the "% increment" value in the level data to 1 for every level, and similarly adjust all goals in all level data from percentage value to actual number of lemmings.  In effect we switch units from "percentage" to "number of lemmings".  Removing the "%" character then completes the picture.  Since the game doesn't check for specific percentage values, the fact that we've switch units will not affect anything.

[Pooty]

This game doesn't even bother with any special messages if you do get 100% or any other "special" % values, you basically just get a "rock bottom" message, a "try harder" message (if you reach at least half of the goal), and then no congratulatory messages (!) if you meet or exceed the goal.

Well... you get a password.

...

Anyway, this does seem like the most popular idea, so I think it should be done. This would make levels such as "Five Alive" possible, rather than "Five Strive to Survive".

[ccexplore]

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.

Okay, curious about the basher glitch, I'm current at the section in your attached disassembly marked "; Data from 3604 to 37CA (455 bytes)", except I can tell it's actually code from $362C onwards, and thus I need that "data" disassembled.  I tried your URL but am not sure any of its numerous links lead directly to a disassembler program (I guess the "Lesson" sections did mention an assembler but I don't know if it does disasembly).  Any chance you can quickly point me to a disassembler download page or better yet, just get that small part disassembled ?  Don't bother if it's too much trouble though, I guess I can find a way later this week on my own.  Thanks in any case.

[Maxim]

This is excellent stuff, I just posted about it over at SMS Power! and I'm happy to provide advice on SMS hacking in general. I may not be a super-regular visitor so feel free to harass me by email...

SMSExamine tries to figure out the executed bits of code and leaves the rest out, marked as data, but it often gets things wrong (especially when there are table lookups). For disassembling, I usually use z80dasm which you can find here: http://www.smspower.org/Development/Tools#Disassemblers

[Pooty]

Hello, Maxim! Thanks for dropping by and giving us a shout at SMS Power! SMS Power and your little corner of that website has helped me get to grips with how the Master System and its games work, so thank you, Bock, and everyone else involved.

z80dasm worked really well, so I'm definitely going to use it more often. Disassembling that part has, as expected, opened up a fairly large rabbit hole, where more Z80 instructions have been mistaken for data. Looks like I'm going to be busy tonight.

[Edit] In the meantime, here's a disassembly of the part ccexplore requested. Copy and pasting it into the source should be sufficient to make it work.