This thread is cross-posted from acmlm board2. The original thread hasn't seen much activity. So to raise community awareness, I decided to post here as well. Basically, the latest points of discussion on MM7 hacking have slightly converged with MMX3 hacking, since both games share a similar engine. I was last looking at the game's object data format, and I would like to get some of the format documented before continuing work on the editor.

In any case, the following is the original post content:


I have been working on a Mega Man 7 editor for quite some time. Rather that regurgitate the history of the project, you can read about it here: http://www.kodewerx.org/wiki/index.php/Syndrome

Some interesting points about this editor:
* It's open source (the most recent source code snapshots are available right now: http://hg.kodewerx.org/syndrome)
* It's written for XULRunner (the same technologies powering Firefox)
* Its application logic is written entirely in JavaScript (for now; eventually it will be necessary to rewrite some of the CPU-intensive parts in C++)
* It's fully cross-platform; tested and running on Mac OS X, Windows XP, and Linux (Ubuntu).
* It can read the Mega Man 7 US ROM with or without an SMC header. The SNES ROM lib I've been writing handles LoROM and HiROM mapping modes.
* It supports opening zipped ROMs directly (PKZIP only! not 7zip or any other archive formats)

Planned features include:
* Non-destructive editing (NDE) - all changes will be possible to undo. Even after saving and closing the project. This will be done with a well-balanced mix of XML files (to keep track of what's been worked on) and UPS format patches (the actual "hack" itself). The idea is to never write directly to the ROM file, but to handle cases where a hacked ROM can be loaded into the editor.
* "Saving" your project will save changes as a UPS format patch file, which will be loadable with emulators supporting the format, and directly distributable on the internet.
* Intuitive editor UI that keeps information overload to a minimum; no more pop-up windows! (or at least keep them to an absolute minimum) Pop-ups are bad for the internet, and they are bad for desktop applications, as well. Support for multiple user paradigms; keyboard-driven, point-n-click-driven, drag-n-drop-driven ...
* Internationalized! It is very simple to translate the UI into any language! Coding experience not required.


Syndrome looks like this:

Mac OS X 10.5


Ubuntu 8.10


Windows XP SP2



Syndrome currently has no UI, and no editing capability. Something I really need to work on before this becomes usable. It does show some promise, however. Considering I've only been working on it for a few hours each night, I think it is progressing along quite quickly.


Objects are currently read and parsed, but the data is not 100% deciphered. The editor can draw a cross-hair and index number on the map in the correct location, but the only way to tell what it's supposed to be is by looking at the remaining "unknown" data for each object.

The objects are capable of changing background palettes and tile sets when Mega Man "touches" them. For these kinds of objects, Mega Man may not have to exactly touch them, but just pass over the X- or Y-coordinate where they live (not verified). The first palette-changing object in the intro stage is object #9.

Objects also describe enemies. The first "Bunby Tank" enemy in the intro stage is object #12. Most enemies are sprites (OAM), some are SNES background layers (e.g Intro stage object #19; Mad Grinder).

Objects also transform the stage itself. A few good examples of this kind of object are objects #1, #2, and #3 in the intro stage; these create the first "unstable road" blocks that stop Auto.


Syndrome can export rendered stages to PNG. Note that the rendering engine is incomplete. Palettes and tiles are incorrect in some locations. Here's a list of exported stages:

http://parasyte.kodewerx.org/projects/syndrome/stages/2009-03-07/ - First exports
http://parasyte.kodewerx.org/projects/syndrome/stages/2009-03-10/ - Exports with object notations


Object tile sets are not resolved or loaded, yet. I've found a good portion of the assembler routines which handle it, but not everything. The first sprite tile set loaded for the intro level is at ROM file (without SMC header) address 0x1BBBE. The five bytes here describe the tile set:

byte-0: tile data length (shift this byte left by 4 to get actual length; if zero, stop processing)
byte-1, byte-2, byte-3: ROM pointer to actual tile data
byte-4: destination offset and end-flag (high bit set indicates processing end, mask lower 7 bits and shift left by 8 to get actual destination offset)

Taking this specific data for example:
3C 40 49 DA 80

Data Length: $03C0
Data Source: $DA4940 (translates to file address 0x1A4940)
Data Destination Offset: $0000 (equates to VRAM location $6000)
End of sprite tile data.

When the end-flag is not set, the game engine processes the next five bytes to load more tile data.


The "battle plan" goes something like this: the editor needs a UI. Some ideas of mine are available on the Kodewerx Wiki (aka "Kwiki"), linked at the top of this post.

It then needs to support fully non-destructive editing. (NDE is popular in photo editors like Photoshop and in many video and audio editors as well. This is usually done by abstracting the editing process with "imaginary" layers.)

To be a complete editor, it needs to handle all objects properly, especially in regard to objects which modify stage design/layout and general game play. These may be the most difficult to deal with since Syndrome wants to display the full stage for editing, rather than working on one screen at a time (like most Mega Man editors do).


If anyone is interested in helping (with data or coding -- come on, it's JavaScript! It's dead simple to work on!) just post here and we'll see if we can get you setup to work on it.

As an aside, please keep in mind that I'm not familiar with the Mega Man series, much less Mega Man 7. The enemy names listed here came from Wikia Gaming. Compare the Syndrome-rendered stages to the rips available at the The Video Game Atlas


Edit: Made some minor adjustments for clarification.

I posted some screenshots a while ago in the screenshots thread (stickied in this forum). That might be where you saw them.

It took a while to get a "development environment" setup for XULRunner. But basically all you need is a text editor and Firefox 3. That's enough to setup the application base and start running it. Right now I'm just using Komodo Edit (on OS X and Ubuntu) and building XULRunner from Mozilla's 1.9.1 branch (http://hg.mozilla.org/releases/mozilla-1.9.1/) to run the application on. Probably the only troublesome part is getting used to the platform.

But I think I'll keep the thread in this forum, if you don't mind. Since some other similar threads are in General Romhacking (like Oracle of Ages) I thought this would be a good place for it! And besides, I think this thread could revolve around all aspects of MM7 hacking, and not just my editor.

There has not been a whole lot of progress on this project, but I did take some time a few days ago to fix the error handling code. I also created a shortcut for Windows users (requires Firefox 3 to be installed).

Progress is markedly slow because I've failed to attract any interest outside of my own.

I did not know about losing data on the forums; that's very unfortunate.

I'm not abandoning the project, in any case. (Not a surprise, considering its very long history!) Just commenting that progress will always be slow if I remain the only contributor.

The only news I have available is that I have been planning some additional rendering speed improvements which should be a very welcome addition. Even with a top-of-the-line computer, the editor still "feels" slow while rendering a stage. My next plan of attack against this issue is to address the perceptual speed directly.

It can be made to "feel" a lot faster by using several tricks. The first of which is to offload the heavy rendering code to worker threads; each thread will be responsible for rendering a 256x256 pixel "screen area" of the entire map, and then blitting it onto the canvas. Second, prioritizing the threads such that the screen areas currently "visible" on the canvas (meaning, within the scrolled view port on the window) will be rendered first. And third, clearing the canvas with the stage's initial background color before initializing any worker threads.

In theory, that should take the [current -- on my laptop] 0.5 second "unresponsive" time after loading the ROM down to a more user-noticeable instantaneous load (showing the blank background color) and then the screens will begin to populate the canvas over the 0.5 second time it takes to do the full rendering. The editor will remain fully responsive while this happens.

Just an idea, but ... better than no news! I will be documenting progress on this particular feature in Bug 7.