Porting stuff between OOT and MM

[43512]

I’ve been experimenting with porting rooms and scenes from MM into OOT and vice versa.  I've gotten it to work successfully in both directions, though thus far it seems that MM->OOT ports are both simpler and less finicky than OOT->MM ports.

 

 

 

I assure you that that's the one from OOT and not the one already in MM.  The glitched water texture should be proof enough of that.

 

 

 

 

After much tinkering around in the scene files and entrance table, I managed not only to port most of Clock Town -- South, North, East, West, and the Laundry Pool -- into OOT, but also to connect the exits and entrances of the different scenes correctly (that is, in the same way as they are in MM).  I had to sacrifice the entrance entries of other maps in the process, but it was for the sake of science.

 

 

With any luck, I’ll be able to figure out what’s causing those texture glitches.  I’d also like to port more levels -- and connect them appropriately, if the entrance table will put up with more abuse -- and some actors on top of what I have here, although I’m unsure how feasible the latter would be.

 

One interesting thing I encountered was that the water in the Laundry Pool made the camera freeze in place once you jumped into it; it remained stuck even after exiting the water.  That went away after I changed the “water/camera properties†field in the water box data from 0101 to 0100.  I don’t know if that’s common knowledge or not, but I’m posting it anyway.

 

At some point, I intend to try something like that Clock Town port in the opposite direction (that is, from OOT into MM).  I also plan on drafting up a tutorial on manual level ports like this, if anyone’s interested.

[Jason777]

Porting to MM is something that has always been trouble. It probably has to do with how MM makes much use of animated textures and sets up RAM segments -- a lot of things were probably simplified from a programmer's standpoint for MM and so these things are probably achieved in a subtley different way.

[DeathBasket]

Porting actors between games would be pretty difficult - someone claimed to have done it once but it was quite obviously fake, which they didn't admit at the time probably because this community has been awful for people wanting to say "I'm better than you" in the past. Anyway, that's kind of irrelevant.

To port actors between the games, you would basically have to find all the function calls made in the actor's code and change their target addresses to be the same function in the other game, if it even exists. That's actually not too hard in itself but becomes a huge pain when most of these functions are not documented at all and you've got to check whether they are taking the same arguments and whatever. You'd also have to find and change any fixed addresses the actor reads from such as the current save file, loaded actor list, etc. and data at these addresses are not structured the same way in both games. Even then, the actor's RAM structure is treated differently in OoT and MM from what I remember so that would probably have an effect too. It's not impossible, but for anything other than a very basic actor it could be quite difficult to get this to work.

[ergoproxysum]

Have you thought of using z64_tables hack by spinout to expand the scene,actor and object tables to make this work a bit more comprehensively/extensively?

[Rather]

Porting actors between games would be pretty difficult - someone claimed to have done it once but it was quite obviously fake, which they didn't admit at the time probably because this community has been awful for people wanting to say "I'm better than you" in the past. Anyway, that's kind of irrelevant.

 

I think the reason they don't show the interface in that video is because the whole thing is actually in Ocarina of Time, not Majora's Mask. It's pretty cool that assets from MM can be directly ported over.

[43512]

Porting actors between games would be pretty difficult - someone claimed to have done it once but it was quite obviously fake, which they didn't admit at the time probably because this community has been awful for people wanting to say "I'm better than you" in the past. Anyway, that's kind of irrelevant.

To port actors between the games, you would basically have to find all the function calls made in the actor's code and change their target addresses to be the same function in the other game, if it even exists. That's actually not too hard in itself but becomes a huge pain when most of these functions are not documented at all and you've got to check whether they are taking the same arguments and whatever. You'd also have to find and change any fixed addresses the actor reads from such as the current save file, loaded actor list, etc. and data at these addresses are not structured the same way in both games. Even then, the actor's RAM structure is treated differently in OoT and MM from what I remember so that would probably have an effect too. It's not impossible, but for anything other than a very basic actor it could be quite difficult to get this to work.

Ah, I see.  I may attempt it at some point, but probably not any time soon.

 

Have you thought of using z64_tables hack by spinout to expand the scene,actor and object tables to make this work a bit more comprehensively/extensively?

It didn't occur to me, though, admittedly, I'm not exactly working toward any major mod or project with all of this; it's more experimentation than anything else.

On a related note, I would like to figure out how to extend the tables in the code file myself, but I suspect I'd have to manipulate the game's assembly code to do that, and I have no clue how to go about doing that.

[SoulofDeity]

The reason that the entire hillside to west clocktown is missing is probably because that part of town is actually an object. I'm not 100% certain, but I think I recall coming across it once while I was browsing objects with UoT. Aside from that, excellent work!

[ergoproxysum]

@43512

 

the ztables hack has most of that done it seems, it relocates those tables to the end of the ROM. I'd like to import all of MM and TP into OOT, that's why I'm messing around with it myself. Just trying to figure out how to add more entries to those now-used tables.

[Twili]

With any luck, I’ll be able to figure out what’s causing those texture glitches.

 

At 0xC58BA0 in a decompressed (U) [!] Majora's Mask ROM is a table for external texture files.

 

Look at the second byte of the header command beginning with 0x11 in a scene file. If it's greater than 00, multiply it by 8 and add it to 0xC58BA0. That offset will show you to the start and end offset (XXXXXXXX YYYYYYYY) of the external texture file that the map uses.

 

Look in the display lists for G_SETTIMG (0xFD) commands with pointers that don't use bank 02 or 03. They will point to within the external texture file.

[43512]

The reason that the entire hillside to west clocktown is missing is probably because that part of town is actually an object. I'm not 100% certain, but I think I recall coming across it once while I was browsing objects with UoT. Aside from that, excellent work!

I'm not sure if it's a separate object, or an external texture file, or some command in the display list that MM and OOT interpreted differently, or what.  It didn't look like any of the other Clock Town maps used external texture files, though; or, at least, they all rendered the majority of their textures properly despite me not porting anything other than the scenes and maps alone.

 

Also, thank you!  ^^  It's really not very impressive, though, considering the texture bugs and so forth.

 

@43512

 

the ztables hack has most of that done it seems, it relocates those tables to the end of the ROM. I'd like to import all of MM and TP into OOT, that's why I'm messing around with it myself. Just trying to figure out how to add more entries to those now-used tables.

Ah, is that so?  I may have to investigate this ztables hack as well.  If you figure anything out about adding more entries to those tables, please let us know how you did it.  I for one would appreciate it.

 

At 0xC58BA0 in a decompressed (U) [!] Majora's Mask ROM is a table for external texture files.

 

Look at the second byte of the header command beginning with 0x11 in a scene file. If it's greater than 00, multiply it by 8 and add it to 0xC58BA0. That offset will show you to the start and end offset (XXXXXXXX YYYYYYYY) of the external texture file that the map uses.

 

Look in the display lists for G_SETTIMG (0xFD) commands with pointers that don't use bank 02 or 03. They will point to within the external texture file.

Thank you for the concise and informative reply.  I looked at the scene file for West Clock Town, however, and the second byte in the 0x11 header command was 00.  Does that mean it doesn't use an external file for its textures?

 

Also, I'm curious as to why the second byte of the header command for the skybox settings would indicate if external texture files are in use.  Is there a known reason why that's the case?

[SoulofDeity]

Also, I'm curious as to why the second byte of the header command for the skybox settings would indicate if external texture files are in use.  Is there a known reason why that's the case?

 

It could be because files like skyboxes and shop/house interiors are all loaded from external texture files even in OoT. Maybe it's a little less specific.

[Twili]

I looked at the scene file for West Clock Town, however, and the second byte in the 0x11 header command was 00.  Does that mean it doesn't use an external file for its textures?

 

West Clock Town uses a separate object for most of its geometry, not an external texture file, yes. I don't know exactly which one at the moment.

[43512]

Porting a level from MM into OOT

 

What you’ll need:

• A hex editor, such as HxD
• A decompressed OOT ROM, such as the Debug ROM
• The scene file for the area you’re porting (.zscene file type)
• The room files corresponding to the above scene (.zmap file type)

 

As an example, I’ll port the Deku Scrub Playground (024D6000 – 024DEE90.zscene and 024DF000 – 024E3360.zmap when extracted from the MM Debug ROM) into the OOT Debug ROM.  Note that this is a “quick and dirty†porting tutorial in the sense that it omits quite a lot of fine-tuning and more technical adjustments; the goal is simply to port the level and get it to load properly.

 

First, open up each of the .zmap files in the hex editor and locate the actor list header command, which will be an 8-byte string near the top of the file with the following format:

 

01 xx 00 00 yy zz zz zz

 

 

Second, change the second byte of the command – the “xx†– to 00.  This tells the game engine not to load any actors when loading the room; the index values representing the actors in MM don’t correspond to those in OOT, so attempting to bring them into memory could cause the game to freeze.

 

Third, locate the object list header command, which is also an 8-byte string at the top of the file, though its format is slightly different:

 

0B xx 00 00 yy zz zz zz

 

 

Fourth, as with the actor list command, change the second byte – again, the “xx†– to 00.  Like before, this instructs the game engine not to load any objects, as the object numbers in MM don’t match the object numbers in OOT and thus could potentially cause a crash.

 

After repeating the above steps for each .zmap file, save the changes, then open up the .zscene file.  Locate the start position list header command, which, like the others, is around the top of the file and has the following format:

 

00 xx 00 00 yy zz zz zz

 

 

Now, go to the position in the file specified by the three rightmost bytes – the “zzâ€.  At that location will be a number of 16-byte strings (specifically, there will be a number of these entries equal to the “xx†field of the header command) with the following format:

 

ww ww xx xx yy yy zz zz pp pp rr rr ss ss vv vv

 

 

Don’t worry about the majority of it; simply change the last two bytes – the “vv†– of each entry to either 0x0FFF or 0x0DFF.  The former makes Link run forward slightly when the area is loaded, and can cause him to step through walls out of bounds and into the void; I recommend the latter, as using it makes Link merely stand still in the specified position when the area is loaded.

 

Next, go back to the top of the file and find the map list command, which is formatted as follows:

 

04 xx 00 00 yy zz zz zz

 

 

 

As with the start positions, go to the file offset specified by the “zz†bytes.  At that offset, there will be several 8-byte strings (as before, an equal number of entries to the “xx†of the command), which have this format:

 

xx xx xx xx yy yy yy yy

 

 

More specifically, the “xx†bytes represent the start of a map file in the full ROM, and the “yy†bytes represent the end of the same map file in the full ROM.  At this point, you’ll have to calculate these offsets.  In the OOT Debug ROM, there is unused space from 0x035CE040 to the end of the ROM; thus, you can calculate offsets by finding the size of each file, adding that value to the free space offset, and recording the old free space offset as the start and the new free space offset as the end.  Here are the new offsets for the Deku Scrub Playground port:

 

Scene size: 0x8E90

Scene start offset: 0x03600000

Scene end offset:   0x03608E90

 

Room size:  0x4360

Room start offset:  0x03610000

Room end offset:    0x03614360

 

Once you’ve calculated the offsets for your files, put the ones for the .zmap (NOT the .zscene) in the scene's map list entry.  Specifically, put the start offset in the “xx†field and the end offset in the “yy†field, and repeat that process for each of the maps.

 

After doing so, save all changes and then insert the files into the ROM at the positions you calculated.  Inserting the files can be accomplished in HxD by selecting the entire file in the hex editor, copying it with Ctrl+C, navigating to the respective offset in the ROM, and pressing Ctrl+B (NOT Ctrl+V, as that will add new bytes into the ROM and change the size of the file).

 

Now that you’ve inserted your files into the ROM, only one step remains:  You must make your level accessible in-game.  To do that, you must add your scene file into the ROM’s scene table, which is basically a list of all of the scene files in the game.  The location of the scene table varies for different versions of OOT; find version-specific offsets here.

 

Since we’re working with the OOT Debug ROM, the scene table is at offset 0xBA0BB0.  Go to that position in the full ROM, then search for the start offset of the existing scene that you wish to replace; find scene starting offsets and table indicies here.

 

In the case of the Deku Scrub Playground, we’ll be replacing the Depth Test scene.  Note that each scene table entry is 20 bytes long and has the following format:

 

xx xx xx xx yy yy yy yy ww ww ww ww zz zz zz zz qq qq qq qq

 

 

The only portions on which to focus here are the “xx†bytes and “yy†bytes, which represent the start offset and end offset of the scene file in question.  Replace these values with the start and end positions that you calculated earlier for your ported scene file.

 

With all of that done, save the changes and boot up the ROM in your emulator of choice.  Select the scene you replaced in the Map Select; with any luck, it’ll load successfully:

 

 

===============

 

Expect a OOT -> MM porting tutorial soon-ish?

[mzxrules]

One thing: I got drunk one night and this happened when I woke up: http://cloudmodding.com/wiki.