I'd like to suggest the following fixes to be included in the next version of the SM64 Level Importer:
The obj_import18S.ppf patch makes some odd changes. I recommend removing the following:
a. Whomp's star spawn location:
0F2DD0: 45728000 -> C3CB0000
b. Mario's shadow size reduction:
12A784: 16000063 00B40064 -> 16000063 00B40046
2. Music volume bug
When the importer applies the fix for the "music volume bug" it seems to only change Mario's shadow size (back to original) and solidity. Is this right? Did I miss something?
12A784: 16000063 00B40046 -> 16000063 00960064
3. Additional Music Settings and Sequences
When the importer applies the fix for additional music settings and sequences, it changes a call from soundAlloc()/0x80317040 to a hard-coded address 0x803D0000.
0D48B4: 0C0C5C10 JAL soundAlloc -> 3C02803D LUI V0,0x803D
0D48B8: 24050100 LI A1,256 -> 34420000 ORI V0,V0,0x0
This works with most emulators, but these addresses are used by the hardware and cen64 for something (probably RSP related). See this console compatibility post
Kaze recommended I use 0x807B0000 and this allows more things to work on the console. I'd recommend changing the fix to use this address or another block you know to be free above 0x80400000.
4. Replace M64 ROM Extender and rom_expand_64.exe
0D48B4: 3C02807B LUI V0,0x807B
0D48B4: 34420000 ORI V0,V0,0x0
I am totally biased, but I highly recommend replacing the slow, cumbersome M64 ROM Extender with the faster sm64extend
. You can either just include the .exe and call it with default settings "sm64extend.exe input.z64 output.z64" or you can pull in the source code
and avoid calling an external EXE altogether. If calling C is too annoying, I can also port it to C# if you like. I'm happy to help in any case, just let me know which route you prefer.
5. Mono Compatibility
There are probably very few Linux and OS X users here, but I think there are just a couple small things that need to be done in the importer to let it run smoothly with under Mono/Wine. As of now, it opens fine but anytime it tries to run one of the .exe, it complains "File .exe not found!". I think this is a combination of the way that the program's path is discovered and the paths are constructed. From looking at the disassembly, I think this is what it is currently doing:
I think this might be more portable:
FileInfo info = new FileInfo(Application.ExecutablePath);
string fullpath = info.DirectoryName + "\\Data\\obj_import.exe";
Let me know if I can do any more testing on my end to help with this.
String path = System.Reflection.Assembly.GetExecutingAssembly().Location;
FileInfo info = new FileInfo(path);
string fullpath = Path.Combine(info.DirectoryName, "Data", "obj_import.exe");