This is an outline for the MaruMari homebrew project I’m working on for NES. As of posting this outline, the game is very incomplete. Things are subject to change, and suggestions are welcome.

Neither the outline nor the spec are complete, but if you think I’ve overlooked something essential, please say so.

Things I Would Love To Have Help With

• Artwork. Can be shamelessly plundered from metroid games, but some unique artwork might be nice, too.
• Music. Famitone/Famitracker is probably the easiest and best approach, but music needs to be composed/extracted, and I have no experience with this toolset. I’ve already written a utility that can extract music data from Metroid.

Gameplay Outline

General Outline:

• Game takes original metroid as its primary inspiration, with each level based on a level from the original game.
• Player will play as samus in ball form.
• Game will used forced downward scrolling.
• The player loses by running out of health or getting crushed at the top.
• It won’t be that hard to avoid getting crushed. The forced scrolling is to motivate the player to keep moving rather than taking a slow cautious approach at the game.
• The game will include powerups and enemies inspired by other metroid games.
• Enemies will probably be based strongly on enemies from the same level of the original game.
• Powerups will be somewhat different from original game (outlined below)
• Each level will end with a door bubble in the floor (as in Super Metroid)
• Player will transition to next level with super-metroid style screen transition
• When player enters door, music stops and screen fades to black, except for doorway and bubble.
• Doorway scrolls to top, next level fades in, bubble opens, and player is dropped down
• The game will not be overly difficult.
• The player should not beat in on first couple tries, but:
• The goal is to complete the game with the highest score possible
• Maybe I can work a “completion percentage” type scoring system in for metroid-y goodness
• Different difficulty settings are a possibility
• Different endings!

Power-ups:

• Bombs
• Limited quantity.
• Enemies may drop pickups, or they may be placed or randomly placed in levels, or both
• A pickup will reward five bombs, player can carry max of eight.
• Rational: This will create a situation where you can’t completely neglect collecting bombs, but you don’t have to hoard them and seek them out obsessively.
• Varia
• Temporary, reduces damage
• Health
• Exactly what it sounds like
• Energy Tank
• Permanently increases health capacity
• Spring ball
• Can work one of two ways:
• Temporary. Lasts a certain amount of time, or jump height decreases gradually.
• Cumulative. Each spring ball pickup increases player’s height
• Charge bomb
• Not really sure about this one
• Player would be able to hold limit quantity (or they could be very rare)
• Would be switched on with select like missiles in “Metroid”
• A longer hold produces a larger blast and bounces player higher
• Space Jump
• Temporary. Allows player to jump from the air anytime he is falling downward.
• Spring ball may or may not be prerequisite
• Screw Attack
• Temporary. Player in invincible and kills enemies on contact while moving upward from a jump.
• Player does not have invincibility while falling down. He still needs to be careful.
• Thoughts
• It might be a good idea to have a plain-old invincibility power up.
• It would be cool to have power bombs instead of/in addition to charge bombs, but how would these work on NES?

Enemies:

• To be determined. Enemy lineup will probably be strongly based on Metroid.

Specifications

Scrolling:

• The game will use a slow forced scrolling to motivate the player to keep moving, to emphasize this is an action game, not an exploration game.
• Scrolling speed will increase with each level to marginal difficulty. Death-by-scroll-pinch isn’t meant to be the primary hazard.
• If the game has difficulty levels, the scrolling could a much more serious hazard in hard difficulty.
• There will be a “scroll line” about halfway down the screen.
• When the player falls past this line, the screen will scroll more quickly to keep the player visually at or above this line.
• This is so the player can proceed at his own pace, and so he can see what’s ahead (he will always be able to see at least 1/2 a screen ahead of the samus)
• The engine will be limited to scrolling at 8 px per frame, so this is the maximum fall speed

Player physics: Movement

• The player has 16-bit speed variables, and 8-bit position variables. Speed is a fixed-point number (i.e. [-]##.##, e.g. -01.C0)
• Position will be stored as a 16-bit value as well.
• The low bytes (fractional part) of speed are not applied to position, they are used only for gradual acceleration
• When the player presses left or right
• If his speed is 00.00, he assumes a speed of 01.00 in the pressed direction so there is no lag before movement.
• For a speed of “01.00″ to the left, we’ll use FF.C0 (-00.40). This is because we always round DOWN rather than toward zero.
• While the player continues to hold left or right
• He accelerates at a rate of 00.40 in the appropriate direction, to a maximum of +/- 2 (FE.C0 to 02.00)
• Note: the speed limit (2) might be a little low.
• If the player exceeds a speed of 2 to the left or right from any yet unplanned mechanism (boost tile or something)
• He decelerates at a rate of 00.40 until he reaches the normal max speed
• If the player is not holding left or right
• He decelerates at a rate of 00.40 until he stops
• When the player jumps
• His upward velocity is set based on current equipment, but assumes full speed instantly. There is no “bounce”.
• When the player is “In-air”
• His downward velocity increases at a constant speed (00.80?) until terminal velocity is reached (06?)
• The player’s sprite should rotate in the direction he most recently moved (left or right)

Player physics: Collision

• Player’s speed will be added to his position (movement) immediately before processing collision
• Tiles with same physics will be stored in groups (consecutive indecies). Groups will appear in the following order.
• Air
• Damage: air-like (tile can be passed through)
• Damage: solid-like (tile can not be passed through)
• Solid
• Vertical Collision
• At any point the player will be in one of two modes. Each will have a different handler.
• “On-ground”
• If the player touches the top of the screen in the on-ground state, he loses (he has been pinched).
• Each frame test ground below player, @ $4,$16 and C,$16. If neither one hits a solid tile, player transitions to in-air state with an initial veloctiy of 01.00
• If the player jumps, he transitions to an in-air state with a negative velocity based on his equipment
• “In-air”
• Checks for collision above or below player, depending on the direction of his motion
• Upward:
• Test for collision at $4,-0 and $4C, -0.
• Player will collide with top of screen
• Upon collision with top, test collision beneath player. If player is touching ground, he loses (he has been pinched)
• Upon collision, player is placed directly beneath the collided-with tile: playerY = (playerY + $F) & $F0
• Player “bounces” downward by assuming a downward velocity that is a fraction of the previous upward velocity
• Downward:
• Test for collision at same points as ‘on-ground’. If a collision occurs:
• Position player onto tile (this can be done by taking the players position, relative to the level grid, and ANDing Y-position with $F0)
• Behavior depends on player’s downward velocity
• If the player has sufficient velocity, “bounce” the player upward (remain in “In-air” mode) at a fraction of his previous speed
• Otherwise, Transition to on-ground state
• Sideways Collision
• Collision is tested in the direction the player is moving (left/right). If the player has no sideways motion, no collision testing is needed.
• Leftward collision points  are $4,0 and $4,$F. If the player collides:
• place him $C pixels to the right of the tile that his left side occupies (playerX = (playerX & $F0) + $C)
• Set horizontal speed to zero
• Rightward collision points are $C,0 and $C,$F. If the player collides:
• place him $4 pixels to the right of the tile that his left edge occupies (playerX = (playerX & $F0) + $4)
• set horizontal speed to zero
• Other
• Background-based hazard detection (spikes, lava, etc) should be included in above collision logic.
• Sprite-based objects (enemies, items) will be processed separately using a collision rectangle created by the collision points detailed above

Level Data Format/Compression:

• Level data will be stored in the following format:
• The data stream will alternate between attribute entries and pairs of row entries.
• After every eighth attribute entry, there will be only one row entry instead of two.
• An attribute entry will consist of eight bytes of raw attribute table (palette) data, enough to define palettes for two rows of 16×16 tiles.
• A row entry will define sixteen tile numbers, using an RLE encoding scheme, where each byte in the stream has the format ATTT BTTT
• The tile number is the value with bits A and B cleared (value AND $EE)
• A and B make up a two-bit number (‘A’ being the low bit) which yields a number 0 to 3. Add 1 to this value to get the run length, in the range of 1 to 4.

Sprite animation data

• Sprite animation data is stored in the form of “sprite layouts”, “sprite tile lists”, and “sprite animations”.
• For each type of data (layouts, tile lists, and animations), there will be a pointer table that references each entry.
• The index of the pointer to a piece of data will be referred to as that data’s ID.
• Sprite Layout:
• Contains a sequence of pairs of bytes that specify X and Y coordinates as signed bytes.
• FF terminated.
• Sprite Tile List:
• Contains a sequence of non-zero tile numbers intermixed with “attribute modifications”
• An attribute modification is a zero byte followed by a byte containing the following bit flags:
• $01 – Add 1 to palette number
• $02 – Add 2 to palette number
• $40 – Toggle horizontal tile flip
• $80 – Toggle vertical tile flip
• FF terminated
• Sprite Animation:
• Contains a sequence of frame entries (3 bytes ea):
• Layout ID
• Tile list ID
• Screen frames for this animation frame
• FF terminated

Keep in mind that this project is incomplete. Comments, suggestions, and criticism are appreciated.

1. Projects

SuiteNES doesn’t work with plain ol’ ROMs. SuiteNES works with projects. A project consists of a ROM, project settings, and project files. But… if you’re doing something simple and don’t want to bother with a project, things are set up so you can basically ignore the whole project aspect of the program.

When you open a ROM, SuiteNES will create a new temporary project for you. You can use the various editors, modify the ROM, and save back to the ROM file without saving the whole project to disk. On the other hand, when you save your project, SuiteNES will remember which editors you have open and their settings. This means that when you open the project back up, it will remember how you had tiles organized in the arranger, how you had the table set up in the hex editor, and so on.

You can open more than one project at a time. Each project opens in its own window (MDI), and each project’s editors are shown within a tabbed interface. This can be handy for copying and pasting tiles or hex between two ROMs, or comparing them side-by-side. Rather than using a “Window” menu, when more than one project is opened, a document list appears at the bottom of the window.

2. Help

To see basic help for the active editor click SuiteNES->Editor Help in the menu. This menu option will be grayed out if help is not available for the current editor.

3. Files

Besides the ROM, a project can contain additional files. On the left side of a project window is a file manager with the files shown on top, and the properties of the selected file shown beneath. Click on the divider bar to collapse the file browser, and click again to show the file manager.

SuiteNES currently only has built-in support for editing and processing .ASM (assembly) and .GFX (graphic tile) files, but any file can be included in the project.

4. Building

SuiteNES uses a build system. Each time you build the project, SuiteNES will process your project files and patch them into a copy of your ROM (found in the \bin directory of the project).

.GFX and .BIN files are patched directly to the ROM. For the file properties, Action should be set to Embed, and Patch offset specifies where the data will be patched (in the 0x00000 hex format).

.ASM files are assembled and patched to the ROM. For assemblers, SuiteNES comes with ASM6 and snarfblASM built-in. To specify which assembler you would like to use, go to the file’s properties and specify ASM6 or snarfblasm as the Command.

External Programs

You can also use an external program to build a file. Suppose you prefer the Foobaz assembler over ASM6. Outside SuiteNES you would run Foobaz with the command Foobaz myfile.asm which will produce a file called myfile.bin.

To configure SuiteNES to use Foobaz to build the file, go to the file’s properties and change Action from Native build to Command line. Set Command appropriately to run Foobaz. For example: Foobaz %FILE%. (You will need to type the full path to Foobaz unless you add the directory that contains Foobaz.exe to the PATH includes in SuiteNES settings.) Build output file should be the name of the output file that Foobaz creates: %FILENAME%.bin. Patch offset specifies the location in the ROM to patch the assembled file (in hex).

5. Debugging

When you build and launch for project (Project->Launch in the menu, or F5), the result ROM is written in the \BIN folder, and then launched with the default .NES file launcher. If you use snarfblASM as your assembler, it will output files for FCEUX’s symbolic debugging. That means code like this:

; Save map data
; -------------
.PATCH 02:B000
SaveMapData:

    JSR PrepLoadSaveIndexers

*   LDA MapRam,X
    STA MapSaveRam,Y

    DEY
    DEX
    BPL -

    JMP SaveHijackReturn

; Load map data
; -------------
LoadMapData:
    JSR PrepLoadSaveIndexers

*   LDA MapSaveRam,Y
    STA MapRam,X

    DEY
    DEX
    BPL -

    JMP LoadHijackReturn

    ; Delete routines
; ---------------
DeleteMap_RegisterName:
    JSR DeleteMap
    JMP $A764       ; Return from hijack

DeleteMap_SecondQuest:
    JSR DeleteMap
    JMP $AF5A       ; Return from hijack

will look like this in the debugger:

02:B000:20 37 B0  JSR PrepLoadSaveIndexers
02:B003:BD 50 7F  LDA MapRam,X @ $804F = #$8D
02:B006:99 60 7F  STA MapSaveRam,Y @ $7F61 = #$FF
02:B009:88        DEY
02:B00A:CA        DEX
02:B00B:10 F6     BPL $B003
02:B00D:4C 2A 9D  JMP $9D2A
02:B010:20 37 B0  JSR PrepLoadSaveIndexers
02:B013:B9 60 7F  LDA MapSaveRam,Y @ $7F61 = #$FF
02:B016:9D 50 7F  STA MapRam,X @ $804F = #$8D
02:B019:88        DEY
02:B01A:CA        DEX
02:B01B:10 F6     BPL $B013
02:B01D:4C 25 E6  JMP $E625
02:B020:20 2C B0  JSR DeleteMap
02:B023:4C 64 A7  JMP $A764
02:B026:20 2C B0  JSR DeleteMap
02:B029:4C 5A AF  JMP $AF5A

 6. Plugins

The plugin system is not complete, and there really aren’t any plugins to use with the plugin system. The eventual goal of the plugin system is to allow new file editors and ROM data editors to be integrated into SuiteNES as well as file builders such as assemblers, text inserters, and anything else you can think of. Most of the plumbing is in place. What really needs work is the plugin managing part of the program.

7. Revisions

Ignore this.

This is not an open or publicly documented format and may be different for different versions. Some of the data types used in the source code are platform-dependant. int, uint, and ushort are implementation-defined and may vary in size. Types with an asterix (*) appended are not confirmed, and are listed as the type they appear to be on a 32-bit platform.

// FCEUX 2.1.5 .DEB FILE FORMAT

// For x86, int is 32 bits, short is 16 bits, byte is 8 bits.
// uint = unsigned int
// ushort = unsigned short
// uint16 = 16-bit unsigned integer
// byte = 8-bit integer

// Debugger Window
byte*           SymbolicDebugEnabled
uint            BookmarkCount
ushort[]        Bookmarks

BreakPoint[65] {
    uint16*         AddressStart
    uint16*         AddressEnd
    byte*           Flags

    uint            ConditionLen
    char[]          Condition
    uint            DescripLen
    char[]          Descrip
}

// Hex Editor Window
int*            HexBookmarkCount
HexBookmark[] {
    uint*           Address
    uint            DescripLen
    char[]          Descrip
}

• Expands ROMs further
  • Converts to CHR ROM – allows animated background tiles
  • 15 KB per level for screens and structures (vs. about 3KB in the original game)
  • 256 combos
  • Up to 32 rooms per level with item-room-music (vs. 7 in the original game)
  • More space for item data than you can use
• Added “NARPASSWORD” (invincibility/all equipment) to room testing feature
• Improved map is larger and auto-hides
• New “Screen Browser” and “Structure Browser” make it easy to find what you’re looking for

Editroid 3.0 with the structure browser

A minor update of Zelda Tech with two fewer bugs. :/

• Zelda Tech 3.4

For completeness, I’ll link to the other downloads here as well.

• Dungeon Master 0.1
• Combo: Zelda Tech 3.4 and Dungeon Master 0.1

In the unlikely event that you do not have the .NET Framework installed, you’ll need to get it to run these programs.

Shootin' through stuff. Freezing stuff. Wavy-Ice can do it all!

I’ve decided to share my simple Wavy-Ice hack. It allows the player to combine the wave beam and ice beam in Metroid. Note that this only works on a ROM expanded by Editroid 2.1. It will not work on an unexpanded ROM or an Editroid 3.0 ROM (I’ll release an updated patch for Editroid 3.0).

I’ve put together a zip containing the code, an assembler, and a ready-to-go IPS patch. The code should be assembled with snarfblASM to produce an IPS file:

>snarfblasm wavyice.asm wavyice.ips -IPS:ON

For your viewing pleasure:

;     .           . · .
;       .       ·       ·       O
;         · . ·           · . ·
;
; Wavy-Ice hack for Metroid
; -------- ---- --- -------
;             by snarfblam
;             (at gmail.com)
;
; Allows combining of wave beam and ice beam.
; Also increases strength of ice, wavy-ice, and
; bombs.
;
; WARNING: THIS CODE IS NOT COMPATIBLE WITH
;          AND UNEXPANDED ROM!
; WARNING: THIS CODE IS NOT COMPATIBLE WITH
;          EDITROID 3.0. If you want to use
;          wavy-ice with a super-expanded
;          ROM, wait until Editroid 3.0 comes
;          out. I'll provide a compatible
;          wavy-ice hack.
;
; Things I Felt Like Saying
; ------ - ---- ---- ------
; - This code is designed to be assembled with
;   snarfblASM. If you want to use another assembler,
;   feel free to break the code up into several files,
;   assemble them separately, and insert them
;   individually.
; - This code is designed to work with an expanded
;   metroid ROM. If you want to use it with an un-
;   expanded ROM you need to:
;     - Move the NEW code to a different location where
;       there is free memory
;     - Change all .PATCH directives to use bank 07
;       instead of 0F.

;===========================================
; Allow weapon combining
; ----- ------ ---------
; NOPs out the code that removes one beam
; when the play aquires another.
;===========================================
.PATCH 0F:DBD2

        NOP ; LDA $6878
        NOP
        NOP

        NOP ; AND #$3F
        NOP

        NOP ; STA $6878
        NOP
        NOP

;===========================================
; New Behavior
; --- --------
; Calls the appropriate routine to update
; beam projectiles.
;===========================================

; Hijack
; ------
.PATCH 0F:D5C5
        JMP $C6B9

; New code
; --- ----
; Updates ice with wave behavior if the player has ice+wave, otherwise
; updates with normal ice behavior

.PATCH 0F:C6B9
        LDA $6878    ; Check equipment
        AND #$40     ; Has wave?
        BEQ NoWave
        JMP $D52C    ; Yes: UpdateWaveBullet
        ;(normally UpdateWaveBullet isn't called when you have ice, even if you do have wave)

    NoWave:
        JMP $D4EB    ; No: UpdateBullet

;===========================================
; New Damage
; --- ------
; Specifies damage amount for wave+ice. Also
; increases damage dealt by bombs and
; vanilla ice. Heh.
;===========================================

; Hijack
; ------
.PATCH 0F:F5EE
        JMP $C6C6

; New Code
; --- ----

.PATCH 0F:C6C6
        ; Y: Weapon type
        ;   1 = Normal
        ;   2 = Wave
        ;   3 = Ice or Wavy-ice
        ;   A = Bomb
        ;   B = Missile (I think)
        ; X: Enemy index
        ; 40B,X: enemy health

        LDY $040E,X        ; Get projectile that hit enemy
        LDA $6878          ; Get current equipment

        CPY #$03           ; If Ice...
        BNE NotIce

    Ice:
        AND #$C0           ;     Does the player have wave and ice beams?
        BNE Damage4        ;     If so, 4 damage
        BEQ Damage2        ;     Else, 2 damage

    NotIce:
    ; Includes vanilla-beam, bomb, wave, and missile
        CPY #$0A           ; Bomb = 4 Damage
        BEQ Damage4
        CPY #$02           ; Wave = 2 Damage
        BEQ Damage2

        BIT $0A            ; Not-a-boss = 1 Damage
        BVC Damage1

    IsABoss:
        CPY #$0B           ; Vanilla-beam = 1 damage
        BNE Damage1        ; (missile will fall thru and do 4 damage)

    Damage4:
        DEC $040B,X
        BEQ exitRoutine
    Damage3:
        DEC $040B,X
        BEQ exitRoutine
    Damage2:
        DEC $040B,X
        BEQ exitRoutine
    Damage1:
        DEC $040B,X

    exitRoutine:
        ; Return to F60F (this is the code that checks if enemies has
        ; 0 HP and if so, kills him)
        JMP $F60F

; Original code
; -------- ----
; Included for comparison
;    cpy #$02                ; Was enemy hit by wave?
;    beq +
;    bit $0A                 ; ?? (Might be a check for boss)
;    bvc ++                  ; If not, do 1 damage
;    ldy $040E,x

;    cpy #$0B                ; Was enemy hit by missile?
;    bne ++                  ; If not, do 1 damage

;    dec EnHitPoints,x       ; Do 4 damage
;    beq +++
;    dec EnHitPoints,x
;    beq +++
;*      dec EnHitPoints,x       ; Do 2 damage
;    beq ++
;*    dec EnHitPoints,x       ; Do 1 damage

"ROM" and "Presets" inputs

Dumper

When you first open the dumper, you’ll get a window with a bunch of confusing check-boxes and hexadecimals. It’s cool, though, you only need to worry about the two things highlighted in red (unless you’re doing something tricky).

Click the button next to the “Rom File” input to browse for a ROM to dump (or just type in the full path). Then select what you want to dump from the “Presets” list. If you want to get tricky, you can select individual songs, or even individual tracks from songs, in the tree to the left (be warned, only one track specifies how long the song should be, and if this track isn’t dumped, the dumper will have a hard time figuring out when to stop dumping music data). There are also a couple of other song-related bits of data you can dump.

The input boxes below the presets are mostly there in case you’ve moved around important data that you’ll probably never move around. Once you’ve picked your ROM and what you want to dump, click “Dump” in the lower-left corner.

Song dump

Editor

When you dump the ROM, the dump is displayed in a text editor in a new tab. There’s lots of confusing stuff in there, which warrants some explanation. The good news is that you can freely ignore a lot of it. Skip down to “<Track> Section” if you don’t like reading. One thing I’ll point out is that comments begin with a double slash, // Like so.

<Context> Section

The <Context> section simply contains all the pointers you were instructed to ignore in the “Dumper” tab (in the form of [Fancy: Tags]). Continue ignoring these. The only tag worth mentioning is the [Bank] tag, which says which ROM bank we are dealing with.

Each level’s data resides in a separate, self-contained bank, and for some songs, there is a separate copy in each bank (for example, the item room music). Each dump file only deals with one bank (you can dump separate banks to separate tabs, however). Changing music data in one bank will never affect music in another bank.

<Song> Section

The <Song> section(s) are optional. They specify properties of the song. [Song] specifies the index of the song we are dealing with (look at the “Dumper” tab to see the list of songs and indecies). [Repeat] specifies whether the song loops.

As a form of compression, the game stores a few lists of pre-defined note lengths that you can use. [NoteLengthTable] specifies which note length table to use (00, 0B, and 17 identify the note length tables used in the game).

[TriangleLength] affects how long notes play on the Triangle song track. 00, 0F, and F0 are the only meaningful values here. I wish I could tell you exactly what they mean. [Sq1VolumeTable] and [Sq2VolumeTable] specify which “volume table” each of the Square song tracks use. This affects the sound of the track’s “instrument.”

<Track> Section

The <Track> section is the good stuff. This is where the music data is actually stored. The [Song] and [Track] tags identify which track of which song the data pertains to. [MaxSize] specifies the largest data size we want to insert. You know, cause we don’t want to overflow into the game’s program and ruin everything. If you need more space for music data, find a large enough unused space for the data, and update [Address] and [MaxSize] accordingly. As far as the actual music data, well, we’ll cover that below.

Other Sections

<NoteTable> defines the pitch of each note. If you change this, the notes shown in Metroid Tuner wont match those heard in the game. <NoteLengthTable> specifies the pre-defined note lengths used in the songs. If you change the note length table, be careful. Some tables affect multiple songs. Each <VolumeTable> helps define one of the game’s instruments. (The other aspect of the instruments is the game’s “duty-cycle and volume” data. If you want to change these values, you’ll need to dig around in Dirty McDingus’ Metroid disassembly.)

Music Data Format

Music data is represented as a list of notes, using the note’s letter, followed by a # for sharp or lowercase “B” for flat, followed by the octave. For example, a middle C would be written as “C4.” The next half-note up would be “C#4″ or “Db4″. Before any notes are listed, a note length must be specified.

Note lengths are specified by the number of frames a note will play. Since the game runs at sixty frames per second, a note length of 60 will play for one second, a note length of 30 will play for half a second, and so on. A note length is written as a colon, followed by a hexadecimal number. For example, “:40″ specifies a note length of 64 frames ($40 in hex = 64 in decimal), or roughly one second. After a note length is specified, all following notes will have that length until a different note length is specified. A dash (“-”) represents a rest (the duration of a rest is specified the same way as any other note).

// Example: first four notes of "When the Saints Go Marching In"
:20   // 0.5 second notes
  C3 E3 F3
:60   // 1.5 second note
  G3

For the “Noise” track, instead of dealing with notes, we deal with sound effects identified by a number in the hex format “$XX”. These numbers are preceded by a dollar sign. $01 is a rest. $02-$05 are meant to be used as drum sounds. Values $06 and up are not meant to be used, but they certainly do seem to produce some sounds. $00 should not be used, but if you insist on using it, it will behave like a song terminator.

Loops are enclosed in {curly braces}, with the number of times the loop will run before the braces. Nested loops are not supported.

// Example: first eight notes of "When the Saints Go Marching In"
2 { // Play these notes twice
    :20   // 0.5 second notes
      C3 E3 F3
    :60   // 1.5 second note
      G3
}

Note that the layout of the music data is completely up to you. The above listing could also be written as the more compact and harder-to-read 2{:20 C3 E3 F3 :60 G3}.

At least one track should have a “song terminator” at the end. This is represented by a double-zero (“00″), without a dollar sign. As the game plays the music, if a song terminator is encountered, all tracks will stop, and playback will begin at the beginning of the song if song is set to repeat. If you forget to include the terminator when you insert, and you try to re-dump the song, the dumper wont know where the end of the song is, and you’ll end up with extra garbage.

One important thing to know is that you are restricted in what note lengths you can use (see <Song> Section). If you want to know which note lengths are allowed, check the check-box labelled “Note Length Table” in the dumper tab (you may have to scroll down). At the end of the dump there will be a list of note lengths.

Inserting

In the toolbar in the text editor window, there is a button with a green arrow. If you hover your mouse over it, a tool-tip appears with the text “Insert”. Click this button. Beware: this is when Metroid Tuner is most prone to violence toward domesticated animals. If everything goes well, it will appear as though nothing has happened. Play the ROM and you’ll find, however, that something has indeed happened. If there are errors, they will be listed at the bottom of the text editor. Right-click the error list to hide it.

Tip: if you want to insert into a ROM without dumping anything first, using the “Dumper” tab, select your ROM, and use the “None” preset. It will bring up a text editor for the ROM with a blank slate where you can paste in your data-to-be-inserted.

Doorways work in pairs. If you look in the door list, two adjacent doors connect together. The level each door appears in is listed, and the arrows show which doors connect to which. Once you understand the controls, it shouldn’t be too tough:

• Left-Click a door in the editor area (on the left) to select it. It will also be highlighted in the door list on the right. Alternatively,
• Click a door in the door list on the right to select it. When you click the door, it will be shown in the editor area on the left.
• Right-Click in the editor area to move the selected door.

Large and small doorways

Note that the yellow door outline has a smaller yellow rectangle in the center. For larger doorways, those that connect levels, the whole yellow rectangle should overlap the doorway. For smaller doorways, those that connect the tank areas to overhead areas, only the smaller inner rectangle should overlap the doorway. (When editing overhead areas, there is only one type of doorway, so we don’t have to deal with this silliness.)

So how do you change the destination of a door? Remember that doors come in pairs. To change where a door leads, simply move the other door in the pair. One thing that might be easy to overlook is that doors can be moved from area to area. For example, take the door that leads from Level 1 to Level 2. If you select the doorway on the Level 2 side, then open Level 5 in the level editor, and right-click to place the doorway, when the player enters the door in Level 1, he will now appear in Level 5 instead of Level 2.

DOWNLOAD IT

ReMaster

The version posted here beforehand was an early build and lacked certain handy features such as undo and stats on building blocks (primarily to inform the user of which level data isn’t being used). The finished version makes good use of all the features of the Romulus level-editor framework.