ROM Hack Super Mario 64 DS editor

[awssk8er]

Try your edited ROMs under DeSmuME. If even DeSmuME can't load them, then there must be something really fucked up

In any case, can you also let me know what versions/regions are the ROMs you are editing?

The original NTSC version. I'll try that emulator.

The emulator didn't work, so I obtained the PAL version of the game and now it's working fine. Thanks.

 

[Arisotura]

Weird. The editor should work with both USA versions... besides if it were data not placed where the editor thinks it is, you'd get 'out of range' type error messages... weird.

 

[Arisotura]

Bringing potentially good news.

I have figured out a way to make SM64DS's level format a lot easier to work with.

Basically, the level data is currently in overlays, mixed up with code for certain objects. The presence of code all around makes it a pain to add more level data. This is why the latest editor release doesn't support adding objects. (fun fact, there actually is code in the editor for that, and even an 'Add object' button- the method I had tried just never worked and kept breaking stuff. Hence I disabled and hid the button)

My idea is to add overlays that will hold the level data, and just it. These overlays will be loaded in place of the old ones. They will have static initializers that will be responsible for loading one of the old overlays- this will be made user-selectable (object bank 7!) so that you can for example use Whomp King in the castle grounds.

The old overlays will remain untouched, though. Avoiding moving blocks of code is apparently one good thing to do. That means old unused data will remain in the ROM- no big deal, the SM64DS ROM is originally 16mb with padding at the end, and that will not be much size increase. (note that the editor also overwrites the padding when more data is to be written inside the ROM) The level format will also get some simplifications that will reduce space usage a little.

However, don't count on it too much- the idea is still in early stages and being experimented. I didn't even get around to adding overlays inside the ROM, for now I'm trying to see how much I can increase the RAM area dedicated to overlays without breaking the game. Because increasing the RAM area dedicated to overlays also means decreasing the RAM area dedicated to the rest of the game. The game's heap management makes it rather easy to resize those two areas, but what would happen if the game fell out of RAM?


For those who don't understand all that technical stuff, long story short, the next editor release will most likely support adding/removing objects and more fancy stuff. But not confirmed right now.

 

[livetek]

Need version 1.1 =/ ...

 

[Arisotura]

It is coming. Besides asking for it will not make it come out faster...

However I can post about the current progress. The plan I described above is being applied, and so far no issues have been met. The tricky part -adding the overlays and getting the game to load them- has been done already, all that remains is copying the level data to the new overlays, and I will also have to port the method to USA ROMs as well.

Due to that, ROMs that have already been patched by v1.0 or v1.01 will need to be re-patched. But no data will be lost during the process.

Note that the plan is not the only new feature planned for v1.1, so it will take more time. Namely, other planned features are text editing and 3D model exporting/importing. As well as an easier-to-use interface.

Also, the guys at the RVLution forums have been suggesting that I rename the editor to 'Dorrie'. What do you guys think about it?

 

[AsPika2219]

Thanks for nice utilities!

 

[RadioShadow]

Basically, the level data is currently in overlays, mixed up with code for certain objects.

My idea is to add overlays that will hold the level data, and just it. These overlays will be loaded in place of the old ones. They will have static initializers that will be responsible for loading one of the old overlays- this will be made user-selectable (object bank 7!) so that you can for example use Whomp King in the castle grounds.

The old overlays will remain untouched, though. Avoiding moving blocks of code is apparently one good thing to do. That means old unused data will remain in the ROM- no big deal, the SM64DS ROM is originally 16mb with padding at the end, and that will not be much size increase. (note that the editor also overwrites the padding when more data is to be written inside the ROM) The level format will also get some simplifications that will reduce space usage a little.

However, don't count on it too much- the idea is still in early stages and being experimented. I didn't even get around to adding overlays inside the ROM, for now I'm trying to see how much I can increase the RAM area dedicated to overlays without breaking the game. Because increasing the RAM area dedicated to overlays also means decreasing the RAM area dedicated to the rest of the game. The game's heap management makes it rather easy to resize those two areas, but what would happen if the game fell out of RAM?

QUOTE(Mega-Mario @ Jan 24 2011, 01:16 PM) I can post about the current progress. The plan I described above is being applied, and so far no issues have been met. The tricky part -adding the overlays and getting the game to load them- has been done already, all that remains is copying the level data to the new overlays, and I will also have to port the method to USA ROMs as well.

First, well done on making this utility. I'll have to try it at some point.

Would you mind explaining how to expand overlays? I ask is because I'm working on an Advance Wars: Dual Strike - War Room Hack (new War Room maps). The main problem is the maps and unit list data are stored in the overlay_0000 (overlay_0005 in the EU version), which doesn't give much room. I could just overwrite the maps, but the main problem is adding in unit data which is uncompressed and can be quite big when lots of units are on the map.

The easy option would be to expand the overlay and add the map and unit data there. Although I would be unsure how much RAM space is allowed for that file. Even if I just use the unit list data in the spare space.

I know the overlay settings are stored in the y9.bin file, although I've not too sure how it is set-up.

Hope you can help with the problem.

 

[Arisotura]

Overlays are documented on GBAtek.

Here is Treeki's overlay decompression code, which should work if your game is standard. (look for DecompressOverlay)
Here is my code, which looks less ASM-ish than Treeki's, if you want...

Hoping this helps

Edit- more notes
- The last word in overlay entries, referred to as 'Reserved (zero)' by GBAtek, is actually information about the overlay's compression. Setting Bit0 of this word to zero disables compression, which lets you reinsert the overlays without recompressing them

- Overlays, most times, also contain code. You have to be careful about that when hacking overlays, especially if the data you're trying to enlarge is all surrounded with code. This is often the case with SM64DS's level overlays, and also the reason I'm setting up crazy patching to move the level data away from that code

 

[loco365]

It is coming. Besides asking for it will not make it come out faster...

However I can post about the current progress. The plan I described above is being applied, and so far no issues have been met. The tricky part -adding the overlays and getting the game to load them- has been done already, all that remains is copying the level data to the new overlays, and I will also have to port the method to USA ROMs as well.

Due to that, ROMs that have already been patched by v1.0 or v1.01 will need to be re-patched. But no data will be lost during the process.

Note that the plan is not the only new feature planned for v1.1, so it will take more time. Namely, other planned features are text editing and 3D model exporting/importing. As well as an easier-to-use interface.

Also, the guys at the RVLution forums have been suggesting that I rename the editor to 'Dorrie'. What do you guys think about it?

Sounds cute.

I suppose it cannot edit landscapes yet, though?

 

[livetek]

Yes Dorrie is nice but for most people who want to find this tool, the name SM64DS editor is more fine ^^
Use Dorrie if you want it

if you need help, we are always here

 

[Luigi39000vr]

Kawaiiedit? :3
Nah just joking, I let my inner weeaboo run wild again.

Dorrie sounds fine

P.S. I'm Luigi987 from ABXD.

 

[Arisotura]

Nothing about 3D editing has been done yet. However, it is planned for the next version.

Also, the rename to 'Dorrie' will go under serious consideration. I received both positive, negative and middle opinions about it. Besides, 'SM64DS Editor', albeit unoriginal, is clearer than anything ever

 

[Arisotura]

The new patching planned for freedom has been finished. It has been tested and so far it is stable. It's also compatible with EUR and USA v1/v2 ROMs.

Basically, SM64DSe v1.1 will let you 32k of free space for each level. For comparison, the biggest level among the original levels is about 19k, and its data is surrounded with object code and whatnot shit. So yeah, 32k big enough for ya guys?

I'm also planning on level importing/exporting, because standard patching would give patches that only work with a certain ROM version, while level files created by the editor would be compatible with any ROM (that is, as far as it has been patched by the editor).

 

[Arisotura]

There's something I want to let you guys know about text editing.

Some ROM versions have additional characters that other versions don't have. For example, the USA ROMs lack all the accented characters that the EUR ROM has.

EUR ROMs also have texts for various language, while USA ROMs only have texts for English and Japanese (?).

These details will have to be taken into account when text-hacking.


Unrelatedly, the editor will be ported to C# (it is currently written in C++/CLI) so that the Linux/Mac guys can use it under Mono (or so I hope; don't have Linux so I'll be unable to test). Request for Linux compatibility came from the Neritic Net guys, apparently most of them are Linux users

 

[Mario92]

So you are saying that E rom has multiple languages so it's best for changing texts? No biggie

Linux support are always welcome. It's really nice when programs work under linux without wine

 

[sightlight]

model importing/exporting? textu import/export? OMG mini mario galaxy?? wee could make a project or something. i wanna join.

 

[Arisotura]

All are planned features for the next version

Projects are always welcome. I sure hope it will get somewhere

 

[sightlight]

Hey Mega,


Suggestions:

A warning message that warns you about if the roms will work once edited.(Crashed Rom)

A warning that tell you that the OJB that the User is trying to add might not be compatible with an existing one.

A bar that tells you about the memory?

A warning that the game might lag because of so many OJB's or something.

I think suggestions like this will help a lot.

If there is anything i could help you wit please tell me. I would like to test or beta test or anything i can help with.
I've took a video with DESMUME of a edited SM64DS but i haven't been able to uploaded it.

 

[Pahicken]

After i hack the crap out of SM64DS im gonna go have a partyfor finding one after all this time that actually works!

 

[sightlight]

Could you rephrase that comment? Im Spanish and i could not understand well what you said.