Prince of Persia

I've just released lemsop, a level editor of Prince of Persia for the Master System.
This is an ALPHA version. It is not yet feature-complete and contains BUGS.

For Windows: lemsop-0.7a-win32.zip (mirror)
For GNU/Linux: lemsop-0.7a.tar.gz (mirror)

Screenshot attached.

Perhaps someone smart can help me improve the editor by explaining to me:

1. How exactly do buttons work?

Running
$ ./lemsop --debug|grep Raise
and
$ ./lemsop --debug|grep Drop
will show you I do understand that the last two bytes of button elements contain a word that I should use.
However, if you look at the (left side of the) attached screenshot of a portion of level 7, you can see the buttons do not directly point to locations (because gate location 321 precedes gate location 313), so there must be a table somewhere that converts button numbers to room/tile locations. But where...

2. How exactly to extract the guard HP?

If you look at the (top right of the) attached screenshot, you can see the guard information that's not part of the enemy elements. But only the level numbers are clear to me, the other bytes seem to combine the health with something else. But with what and how...

3. What exactly are the 'stuff' values?

Each level contains 25 words with 'stuff'.
$ ./lemsop --debug|grep Stuff
I don't know what this information is.
The stuff is stored after the elements.
See the LoadLevel() function for details.

Any information that allows me to improve this editor is welcome.
Of course, I'll thank those who helped in docs/README.txt of future releases.

It's very similar to apoplexy

Emiliano Fierro wrote: ↑October 17th, 2019, 10:22 pmIt's very similar to apoplexy

Yes.

I won't use it because of this
viewtopic.php?f=73&t=4387&p=26601&hilit=Quiting#p26601
But I would like to learn

Norbert wrote: ↑October 17th, 2019, 6:49 pm 3. What exactly are the 'stuff' values?
Each level contains 25 words with 'stuff'.
[...]
The stuff is stored after the elements.

You're looking at it the wrong way: This "stuff" is stored before the room links, and your editor is reading the "stuff" of the next level.

Basically, there is a level table starting at 0x6A7C, with 20 bytes per level.
You're already using the part of it which tells where the prince starts the level (arOffsetKid[] in your code).
However, it also contains (among others) the addresses of the level data (room links + elements), at the end of each table entry.

For example, for level 1, at offset 0x6A8E (= 0x6A7C + 0x12) is the address 0xAD8E.
At offset 0xAD8E the first thing is the length of the data in the following chunk of data. This is the first word of the "stuff".
Within this chunk, the first 24 words are offsets to the elements of each room. This is the rest of the "stuff".
After this, the chunk contains the room links and the elements, which the editor can already handle.

Norbert wrote: ↑October 17th, 2019, 6:49 pm 1. How exactly do buttons work?
[...]
will show you I do understand that the last two bytes of button elements contain a word that I should use.
However, if you look at the (left side of the) attached screenshot of a portion of level 7, you can see the buttons do not directly point to locations (because gate location 321 precedes gate location 313), so there must be a table somewhere that converts button numbers to room/tile locations. But where...

These two bytes are simply an offset into the chunk of level data I mentioned above.
They always point at the first byte of the triggered object.

If you look at the numbers of the gates in room 16 on the picture, they are 297, 305, 313, 321.
Each is 8 more than the last one, and 8 is the number of bytes in a gate definition.

Norbert wrote: ↑October 17th, 2019, 6:49 pm Any information that allows me to improve this editor is welcome.

I'm writing a wiki article which will explain these in more detail.

David wrote: ↑October 19th, 2019, 12:04 pmI'm writing a wiki article which will explain these in more detail.

Cool.

Norbert wrote: ↑October 19th, 2019, 3:31 pm

David wrote: ↑October 19th, 2019, 12:04 pmI'm writing a wiki article which will explain these in more detail.

Cool.

Here is the first version: https://www.princed.org/wiki/SEGA_Master_System_format

David wrote: ↑October 19th, 2019, 6:33 pmHere is the first version: https://www.princed.org/wiki/SEGA_Master_System_format

Thanks. If you look on the elements screen of the editor and click the elements' checkboxes, you will find some additional information about them not yet mentioned in the wiki. For example, the middle byte of raise and drop buttons is 00 without and 02 with a wall portion. If you go to room 8 of level 1 and replace all tiles with black (middle mouse on the black square on the tiles screen), then you can see what a dungeon drop button with a wall looks like at its actual location. Another example are the enemies (0x64). I'll update the wiki tomorrow. You do know you can already change and save the elements' bytes on that elements screen, right?

Norbert wrote: ↑October 20th, 2019, 2:07 amI'll update the wiki tomorrow.

https://www.princed.org/w/index.php?tit ... oldid=1922
I added 0xB5 after 0x64, because I think it's the animation, and they are always together.
And I added 0xDE after 0x29, also always together.
But feel free to undo whatever you think I got wrong.

Norbert wrote: ↑October 20th, 2019, 4:56 pm

Norbert wrote: ↑October 20th, 2019, 2:07 amI'll update the wiki tomorrow.

https://www.princed.org/w/index.php?tit ... oldid=1922

I've updated the page as well: https://www.princed.org/w/index.php?tit ... oldid=1924
I've also added it to the Documents page: https://www.princed.org/w/index.php?tit ... oldid=1921


I see you added a note to the princess (0x6F) saying "object is added later?".
If you mean that your editor doesn't display her, that's a bug in the editor.
As the result of the same bug, the editor doesn't show the level door on level 14 either.
The editor should find the objects by following the offsets shown in the wiki page.

The 0x6F byte is at offset 0xBF0F.
If you change it to something else then the princess on level 14 will be replaced with the object corresponding to the new byte.

The prince will stop when he reaches the place where the princess should be, and the game gets stuck.

Norbert wrote: ↑October 20th, 2019, 4:56 pm I added 0xB5 after 0x64, because I think it's the animation, and they are always together.
And I added 0xDE after 0x29, also always together.
But feel free to undo whatever you think I got wrong.

I see you added 0x40 after 0x3E and 0x3F as well, so I deleted the stand-alone 0x40.
I'm not sure about this one, though, since 0x40 can be used by itself to make a skeleton.

Norbert wrote: ↑October 17th, 2019, 6:49 pm 2. How exactly to extract the guard HP?

I explained it in the wiki article in today's update.
It's indeed stored in the separate table which you showed (together with other data about the guards), and the table is indexed by the "color and dir" byte of the guard (and that of the skeletons as well).

By the way, how did you find that table?
Or everything you use in LoadLevel(), for that matter?
Or that tiles are 6 bits each?
I'm curious.

David wrote: ↑October 26th, 2019, 9:25 pmBy the way, how did you find that table?
Or everything you use in LoadLevel(), for that matter?
Or that tiles are 6 bits each?
I'm curious.

I brute-forced my way to somewhat understanding the ROM. When creating an editor for a port whose format you have not yet (publicly) documented, I generally start with my hexmover tool from the hextools package. (Attached to a post somewhere on this forum...) I have it change 30 bytes at a time at consecutive offsets, and during each iteration I playtest - with the fast-forward key down - until the guard before the level exit door. This generally allows me to find interesting offsets in the image. I see room links, tiles, guard characteristics, etc. change. I then move on to modifying individual bytes at and near all these offsets using a hex editor, and doing more playtesting. It's time-intensive, but it's entertaining to see all kinds of weird things happen to the game during this process. As we've seen, it's not a foolproof method.

Thanks for updating the wiki.
I'm currently busy with a non-PoP project, but one day I'll improve lemsop.

David, could you also add LinearToBanked().
Also, I'm wondering what is the purpose of the commented out line in BankedToLinear().

Norbert wrote: ↑March 22nd, 2020, 5:14 pm David, could you also add LinearToBanked().

Done: https://www.princed.org/w/index.php?tit ... oldid=1928

I see you removed your note about the princess: https://www.princed.org/w/index.php?tit ... oldid=1926
Did you get your editor to load level 14 correctly?

Norbert wrote: ↑March 22nd, 2020, 5:14 pm Also, I'm wondering what is the purpose of the commented out line in BankedToLinear().

It's just a condition which should be true, otherwise the input is probably invalid.
You could possibly write an error message to the console if the condition is false.

David wrote: ↑March 22nd, 2020, 8:14 pmDone: https://www.princed.org/w/index.php?tit ... oldid=1928

Thank you.

David wrote: ↑March 22nd, 2020, 8:14 pmDid you get your editor to load level 14 correctly?

Yes. I'm working on the next release. Will take a while longer, but I'm making progress.

David wrote: ↑March 22nd, 2020, 8:14 pmYou could possibly write an error message to the console if the condition is false.

Okay.