ROM Hack SM64DS Text Editor

[Fiachra]

Hi,

I have added the ability to edit text in Kuribo's SM64DS Editor (previously you could just read all the text data).

Kuribo (Mega-Mario) did had most of the work done already, I just added the ability to make changes.



Latest version rev. 29 07/01/2013
Collision generating is now perfect, collision viewer/terrain type editor, minimap editing and other new features. See http://code.google.com/p/sm64dse/ and kuribo64.cjb.net for the latest information.

It's best you use the European rom for text editing as it has a much larger range of characters available:



Editing Japaneses text is not currently available.

See http://code.google.com/p/sm64dse/ for latest version.

 

[Dirbaio]

Cool. `You should probably contact Mega-Mario directly instead...
BTW "Kuribo" is the name of the Kuribo64 forum, not Mega-Mario's.

 

[Arisotura]

Kuribo here!

Seriously, I'm glad that after so long, someone finally showed enough interest in SM64DSe to dare touch the code.

Anyway, how much programming do you know? It'd be interesting if you were planning on coding more stuff.

Plans are being made with a few other people (Skelux and blank) to try and fix the model importer's collision, which has always been the number one issue. If we can succeed, this will be a rebirth for SM64DS hacking.


Thank you for your work, anyway.

 

[Fiachra]

Hi,

I'm currently studying C# and Java in Computer Science. I have decent knowledge of the basics including object-oriented programming. However, I've never done rom hacking or 3d programming before.

I was going to try and add other languages to translate and the characters for them. I was also going to try importing custom objects and look at the fact only some levels allow you to import custom levels (eg. Bob-omb battlefield does but whomp's fortress doesn't).

I'd be interested in working on the project though I don't think I could help much with collision detection but I'm willing to try.

Fiachra.

 

[Arisotura]

Java too? That's nice. If we give SM64DSe a rebirth, we'll most likely port it to Java, for better portability. The OpenTK interface just won't work right under Linux.

Also, try to not bother about translations until the end of the development cycle. If you add translations before the end, they become a pain in the ass to manage. Random people who come and make a translation into a weirdass language and then disappear forever make it even worse.

Levels like Whomp's Fortress don't allow custom models because of the texture animation data. The original models have data in the level headers associated to them, to animate certain textures, like water. The texture animation data refers to materials by their names. If you import a new model, the texture animation data will refer to nonexistant materials, which will crash the game. One solution would be knowing the names of animated materials, and making sure the new model has materials with those names.

 

[jonthedit]

Sweeeeet!!!! +REP!!!
I've been waiting for this since 2009! ^>^
-REP
It turns out the scripter didn't bother to make a "All Users" Feature...

System.Exception: NitroROM: cannot find file 'data/message/msg_data_eng.bin'
  at SM64DSe.NitroROM.GetFileFromName(String name) in C:\Users\Fiachra Murray\Documents\Visual Studio 2010\Projects\SM64DSe\NitroROM.cs:line 294
  at SM64DSe.TextEditorForm.TextEditorForm_Load(Object sender, EventArgs e) in C:\Users\Fiachra Murray\Documents\Visual Studio 2010\Projects\SM64DSe\TextEditorForm.cs:line 44
  at System.Windows.Forms.Form.OnLoad(EventArgs e)
  at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
  at System.Windows.Forms.Control.CreateControl()

 

[Fiachra]

Also, try to not bother about translations until the end of the development cycle. If you add translations before the end, they become a pain in the ass to manage. Random people who come and make a translation into a weirdass language and then disappear forever make it even worse.

Hi,
Sorry, I meant that at the minute it only edits msg_data_eng.bin - I was going to try to add the msg_data_frn, gmn, itl, spn, nes(US) files as well and the ability to save text that includes characters like áéíóú etc. I didn't mean translating the program.

Levels like Whomp's Fortress don't allow custom models because of the texture animation data. The original models have data in the level headers associated to them, to animate certain textures, like water. The texture animation data refers to materials by their names. If you import a new model, the texture animation data will refer to nonexistant materials, which will crash the game. One solution would be knowing the names of animated materials, and making sure the new model has materials with those names.

Would it be possible to remove the animation data? Or to copy all the data from Bob-omb battlefields header into the others and then be able to import custom levels?

Sweeeeet!!!! +REP!!!
I've been waiting for this since 2009! ^>^
-REP
It turns out the scripter didn't bother to make a "All Users" Feature...

System.Exception: NitroROM: cannot find file 'data/message/msg_data_eng.bin'
  at SM64DSe.NitroROM.GetFileFromName(String name) in C:\Users\Fiachra Murray\Documents\Visual Studio 2010\Projects\SM64DSe\NitroROM.cs:line 294
  at SM64DSe.TextEditorForm.TextEditorForm_Load(Object sender, EventArgs e) in C:\Users\Fiachra Murray\Documents\Visual Studio 2010\Projects\SM64DSe\TextEditorForm.cs:line 44
  at System.Windows.Forms.Form.OnLoad(EventArgs e)
  at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
  at System.Windows.Forms.Control.CreateControl()

Hi, it currently only works with the European Rom, though I will be trying to fix that - it should just be setting the program to open "msg_data_nes.bin" instead of "msg_data_eng.bin" if it's the US Rom.

 

[Arisotura]

If you're going to add international support to your text editor, you might find this thread useful.

As for the animation data, having the editor remove it is a possibility. Here's my doc about the level format generated by SM64DSe:

Spoiler

---===[ SM64DS LEVEL FORMAT DOC ]===---
By Mega-Mario

---===[ WHERE TO FIND THE DATA ]===---
In a clean ROM, the level data is found in overlays 8 to 59 (one overlay per level).
However, that level data has no unified structure, and is all surrounded with code and
data relating to certain objects, so it is a pain to modify without breaking the game.

SM64DSe, since version 1.1, creates new overlays (typically overlays 103 to 154), and moves
each level's data in its new overlay, restructuring it in a more unified structure. The new
overlays are also programmed to load the old overlays they are replacing, so that objects
relying on the old overlays still work.

---===[ LEVEL HEADERS ]===---
Level header as generated by SM64DSe v1.1 (patch version 2).

Offset Size Desc
00 84 Overlay initializer/deinitializer code
54 1 Object bank 0 setting
55 1 Object bank 1 setting
56 1 Object bank 2 setting
57 1 Object bank 3 setting
58 1 Object bank 4 setting
59 1 Object bank 5 setting
5A 1 Object bank 6 setting
5B 1 Zero
5C 4 Object bank 7 setting
60 4 Address of the CLPS chunk
64 4 Address of the 'misc' objects table
68 2 Internal file ID of the level model (.bmd)
6A 2 Internal file ID of the level collision map (.kcl)
6C 2 Internal file ID of the minimap tileset (.icg)
6E 2 Internal file ID of the minimap palette (.icl)
70 4 Address of the level area data
74 1 Number of level areas
75 1 Zero (?)
76 2 Scale factor for minimap coordinates
78 1 bit0-3: ??? (always 0xF), bit4-7: sky/background (0=none, or 1-11)
79 3 Zero (?)
7C 24 Reserved for future use
94 ... Level data

This header is generated by SM64DSe's patching, and isn't found under this form in the original game data.
However, the block from 0x60 to 0x7C (28 bytes) can be found in a similar format in the original level overlays,
but at varying offsets. The block from 0x54 to 0x5B (7 bytes) is originally hardcoded in the game binary.
The dword at 0x5C isn't an original feature of the game engine-- it is made possible by the new level format only.
All the data past 0x94 is copied from the original level overlays.

---===[ LEVEL AREA DATA ]===---
Each entry is 12 bytes. Number determined by header[0x74].

Offset Size Desc
00 4 Address of the objects table (NULL = no table)
04 4 Address of the texture animation data (NULL = no data)
08 1 Minimap tilemap index
09 3 ???

The objects table uses the same format as the one header[0x64] points to.
Except it typically only contains objects of type 0 and 5. The other object
types are contained by the header[0x64] table.

---===[ OBJECT TABLES ]===---
First part: 8 bytes

Offset Size Desc
00 4 Number of entries in table
04 4 Address of the object table

Object table: 8 bytes per entry

Offset Size Desc
00 1 Bit0-4: object type; Bit5-7: layer (0=all stars, 1-7=star 1..7)
01 1 Number of objects
02 2 Zero (?)
04 4 Address of the object list

Valid object types:
* 0: level objects, standard format (16 bytes per object)
* 1: level entrances (16 bytes per object)
* 2: path nodes (6 bytes per object)
* 3: paths (6 bytes per object)
* 4: views/camera anchors (14 bytes per object)
* 5: level objects, simple format (8 bytes per object)
* 6: teleport source points (8 bytes per object)
* 7: teleport dest. points (8 bytes per object)
* 8: fog (8 bytes per object)
* 9: doors/inter-area warps (12 bytes per object)
* 10: level exits (14 bytes per object)
* 11: minimap tilemap file IDs (2 bytes per object)
* 12: unknown (2 bytes per object)
* 14: unknown (4 bytes per object)

---===[ OBJECT TYPE 0: LEVEL OBJECTS (STANDARD) ]===---
16 bytes per object.

Offset Size Desc
00 2 Object ID
02 2 X position (divide by 1000 to obtain 3D coordinate)
04 2 Y position
06 2 Z position
08 2 Object-specific parameter (2)
0A 2 Y rotation (0x0400 = 90°)
0C 2 Object-specific parameter (3)
0E 2 Object-specific parameter (1)

The first two object-specific parameters (2 and 3 in SM64DSe) should be X and Z rotation, respectively.
However, most objects ignore them. A few objects use them as X/Z rotation, and some other objects use it for other purposes.

---===[ OBJECT TYPE 1: ENTRANCES ]===---
16 bytes per object.

Offset Size Desc
00 2 Must be zero (?)
02 2 X position
04 2 Y position
06 2 Z position
08 2 Parameter (?)
0A 2 Y rotation
0C 2 Parameter (?)
0E 2 Parameter (meaning=idk; weird)

---===[ OBJECT TYPE 2: PATH NODES ]===---
6 bytes per object.

Offset Size Desc
00 2 X position
02 2 Y position
04 2 Z position
06 6 Parameters (?)

---===[ OBJECT TYPE 3: PATHS ]===---
6 bytes per object.

Offset Size Desc
can't remember... wait

---===[ OBJECT TYPE 4: VIEWS/CAMERA ANCHORS ]===---
14 bytes per object.

---===[ OBJECT TYPE 5: LEVEL OBJECTS (SIMPLE) ]===---
8 bytes per object. This format is commonly used for objects like trees and coins, that don't require extensive parameters.

Offset Size Desc
00 2 bit0-8: object ID; bit 9-15: object-specific parameter (1)
02 2 X position
04 2 Y position
06 2 Z position

---===[ TEXTURE ANIMATION DATA ]===---
24 bytes per entry.

Offset Size Desc
00 4 Total number of frames?
04 4 Address of the scale values table (4 bytes each, 20:12 fixedpoint)
08 4 Address of the rotation values table (2 bytes each, 0x0400 = 90°)
0C 4 Address of the translation values table (4 bytes each, 20:12 fixedpoint. Translation orientation defined by rotation)
10 4 Number of animations
14 4 Address of the animation data

Animation data: 28 bytes per entry.

Offset Size Desc
00 4 ???
04 4 Address of the name of the material with the texture to animate (null-terminated ascii string)
08 4 ???
0C 2 Number of scale values
0E 2 Start offset in dwords in the scale values table
10 2 Number of rotation values
12 2 Start offset in words in the rotation values table
14 2 Number of translation values
16 2 Start offset in dwords in the translation values table
18 4 ???

 

[Fiachra]

If you're going to add international support to your text editor, you might find this thread useful.

As for the animation data, having the editor remove it is a possibility. Here's my doc about the level format generated by SM64DSe:

Spoiler

---===[ SM64DS LEVEL FORMAT DOC ]===---
By Mega-Mario

---===[ WHERE TO FIND THE DATA ]===---
In a clean ROM, the level data is found in overlays 8 to 59 (one overlay per level).
However, that level data has no unified structure, and is all surrounded with code and
data relating to certain objects, so it is a pain to modify without breaking the game.

SM64DSe, since version 1.1, creates new overlays (typically overlays 103 to 154), and moves
each level's data in its new overlay, restructuring it in a more unified structure. The new
overlays are also programmed to load the old overlays they are replacing, so that objects
relying on the old overlays still work.

---===[ LEVEL HEADERS ]===---
Level header as generated by SM64DSe v1.1 (patch version 2).

Offset Size Desc
00 84 Overlay initializer/deinitializer code
54 1 Object bank 0 setting
55 1 Object bank 1 setting
56 1 Object bank 2 setting
57 1 Object bank 3 setting
58 1 Object bank 4 setting
59 1 Object bank 5 setting
5A 1 Object bank 6 setting
5B 1 Zero
5C 4 Object bank 7 setting
60 4 Address of the CLPS chunk
64 4 Address of the 'misc' objects table
68 2 Internal file ID of the level model (.bmd)
6A 2 Internal file ID of the level collision map (.kcl)
6C 2 Internal file ID of the minimap tileset (.icg)
6E 2 Internal file ID of the minimap palette (.icl)
70 4 Address of the level area data
74 1 Number of level areas
75 1 Zero (?)
76 2 Scale factor for minimap coordinates
78 1 bit0-3: ??? (always 0xF), bit4-7: sky/background (0=none, or 1-11)
79 3 Zero (?)
7C 24 Reserved for future use
94 ... Level data

This header is generated by SM64DSe's patching, and isn't found under this form in the original game data.
However, the block from 0x60 to 0x7C (28 bytes) can be found in a similar format in the original level overlays,
but at varying offsets. The block from 0x54 to 0x5B (7 bytes) is originally hardcoded in the game binary.
The dword at 0x5C isn't an original feature of the game engine-- it is made possible by the new level format only.
All the data past 0x94 is copied from the original level overlays.

---===[ LEVEL AREA DATA ]===---
Each entry is 12 bytes. Number determined by header[0x74].

Offset Size Desc
00 4 Address of the objects table (NULL = no table)
04 4 Address of the texture animation data (NULL = no data)
08 1 Minimap tilemap index
09 3 ???

The objects table uses the same format as the one header[0x64] points to.
Except it typically only contains objects of type 0 and 5. The other object
types are contained by the header[0x64] table.

---===[ OBJECT TABLES ]===---
First part: 8 bytes

Offset Size Desc
00 4 Number of entries in table
04 4 Address of the object table

Object table: 8 bytes per entry

Offset Size Desc
00 1 Bit0-4: object type; Bit5-7: layer (0=all stars, 1-7=star 1..7)
01 1 Number of objects
02 2 Zero (?)
04 4 Address of the object list

Valid object types:
* 0: level objects, standard format (16 bytes per object)
* 1: level entrances (16 bytes per object)
* 2: path nodes (6 bytes per object)
* 3: paths (6 bytes per object)
* 4: views/camera anchors (14 bytes per object)
* 5: level objects, simple format (8 bytes per object)
* 6: teleport source points (8 bytes per object)
* 7: teleport dest. points (8 bytes per object)
* 8: fog (8 bytes per object)
* 9: doors/inter-area warps (12 bytes per object)
* 10: level exits (14 bytes per object)
* 11: minimap tilemap file IDs (2 bytes per object)
* 12: unknown (2 bytes per object)
* 14: unknown (4 bytes per object)

---===[ OBJECT TYPE 0: LEVEL OBJECTS (STANDARD) ]===---
16 bytes per object.

Offset Size Desc
00 2 Object ID
02 2 X position (divide by 1000 to obtain 3D coordinate)
04 2 Y position
06 2 Z position
08 2 Object-specific parameter (2)
0A 2 Y rotation (0x0400 = 90°)
0C 2 Object-specific parameter (3)
0E 2 Object-specific parameter (1)

The first two object-specific parameters (2 and 3 in SM64DSe) should be X and Z rotation, respectively.
However, most objects ignore them. A few objects use them as X/Z rotation, and some other objects use it for other purposes.

---===[ OBJECT TYPE 1: ENTRANCES ]===---
16 bytes per object.

Offset Size Desc
00 2 Must be zero (?)
02 2 X position
04 2 Y position
06 2 Z position
08 2 Parameter (?)
0A 2 Y rotation
0C 2 Parameter (?)
0E 2 Parameter (meaning=idk; weird)

---===[ OBJECT TYPE 2: PATH NODES ]===---
6 bytes per object.

Offset Size Desc
00 2 X position
02 2 Y position
04 2 Z position
06 6 Parameters (?)

---===[ OBJECT TYPE 3: PATHS ]===---
6 bytes per object.

Offset Size Desc
can't remember... wait

---===[ OBJECT TYPE 4: VIEWS/CAMERA ANCHORS ]===---
14 bytes per object.

---===[ OBJECT TYPE 5: LEVEL OBJECTS (SIMPLE) ]===---
8 bytes per object. This format is commonly used for objects like trees and coins, that don't require extensive parameters.

Offset Size Desc
00 2 bit0-8: object ID; bit 9-15: object-specific parameter (1)
02 2 X position
04 2 Y position
06 2 Z position

---===[ TEXTURE ANIMATION DATA ]===---
24 bytes per entry.

Offset Size Desc
00 4 Total number of frames?
04 4 Address of the scale values table (4 bytes each, 20:12 fixedpoint)
08 4 Address of the rotation values table (2 bytes each, 0x0400 = 90°)
0C 4 Address of the translation values table (4 bytes each, 20:12 fixedpoint. Translation orientation defined by rotation)
10 4 Number of animations
14 4 Address of the animation data

Animation data: 28 bytes per entry.

Offset Size Desc
00 4 ???
04 4 Address of the name of the material with the texture to animate (null-terminated ascii string)
08 4 ???
0C 2 Number of scale values
0E 2 Start offset in dwords in the scale values table
10 2 Number of rotation values
12 2 Start offset in words in the rotation values table
14 2 Number of translation values
16 2 Start offset in dwords in the translation values table
18 4 ???

Thanks for these, that must've taken ages to work out!
That thread's very helpful, will save me trying to work out the positions!

Offset Size Desc 00 4 Address of the objects table (NULL = no table) 04 4 Address of the texture animation data (NULL= no data) 08 1 Minimap tilemap index 09 3 ???

It looks like it should be possible to go through all level data entries in each overlay and set the texture animation address to NULL. I'll try and see if I can do that in next few days.

 

[Arisotura]

Setting the address to NULL would do it.

Also, for the object formats and all, I fear the doc is incomplete. The best documentation is still to look into SM64DSe's code

 

[Fiachra]

Got it working. All the texture animation address pointers have been set to null (the user is given a choice when patching) which means custom models work in all the levels.

Download from first post.

 

[Arisotura]

Nice.

I'm tempted to give you write access to the SM64DSe repo. Would you be interested?

 

[Fiachra]

Yeah, definitely. Thanks.

 

[Max2010]

after pathing this game using Text Editor the game won't start on nds.
The game runs only on the emulator? Fonts not working, limited number of characters.
What can I do to make the game work on a console? If you do not run on the nds it will be a...
crap?

 

[Fiachra]

It's working fine for me:



The problem seems to be you're trying to use characters not supported by the US rom. For text editing it's recommended you use the European rom as it has WAY more characters available:



I should have mentioned that though, I'll update the first post.

 

[Vinnymac]

As a fellow CS Major, it is nice to see this making so much progress. You guys are going to put me in tears with your open discussion and sharing of information. I wish more collaborations went so smoothly. Good work Fiachra :]

 

[Fiachra]

As a fellow CS Major, it is nice to see this making so much progress. You guys are going to put me in tears with your open discussion and sharing of information. I wish more collaborations went so smoothly. Good work Fiachra :]

Thanks for your support

There's more discussion of it at the official forum (http://kuribo64.cjb.net/)
SM64DS stuff is under Misc. Rom Hacking and some recent updates in Announcements.

As well as the text editor there's now the option to import custom object models (but not animated ones) and exporting the level models (no textures yet):

 

[Max2010]

yeap.. but these game don't work for me. I tried to run on the nds and there is no effect.
Fonts not working. Here is an example:

[/IMG]

 

[Fiachra]

What version of the rom are you using? It's still fine for me using the EUR rom:



same on the DS console.

Are you using the version in the first post (13122012)? In some of the earlier ones some text could become corrupted when I was resizing the string entries to fit longer/shorter text but it's working fine in the newest version (first post, or newer updates from the Google Code repo).

 

[Max2010]

I mean fonts (A B X Y L R) for each trigger.
I'm using version 0022 - Super Mario 64 DS (E) (M5) / 0022 - Super Mario 64 DS (E)(Wet 'N' Wild) and Super Mario 64 DS. (PAL)
Is there any way to run this game on nds? After modifying the text these game not working on nds. Whay?

Edit. the answer is: Patched ROMs work on R4 flashcarts.
Only R4 flashcarts? I just have M3DSREAL ..

Hovewer - great job;]