News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - snarfblam

Pages: 1 ... 18 19 20 21 22 [23]
Personal Projects / Re: SuiteNES - Plug-in based hacking tool
« on: November 18, 2010, 12:18:06 pm »
Got my project system going. Not exactly a complete versions control system, but I think it does the trick for rom hacking. It also saves the state of the open editors, so you can close the project and open it later with everything as you've left it.

Now I need to figure out how I can have interoperation between plug-ins. Late-binding would be a breeze in VB, but since I'm not targeting .NET 4.0, it's not available in C#.

Code: [Select]
' VB
Dim patternEditor = host.GetEditor("IPatternEditor", InstanceOptions.CreateIfNeeded)
patternEditor.OpenPatternsForEdit(offset, patternCount)

// C#, not so pretty!
object patternEditor = host.GetEditor("IPatternEditor", InstanceOptions.CreateIfNeeded);
    new object[] { offset, patternCount});

Personal Projects / Re: SuiteNES - Plug-in based hacking tool
« on: October 28, 2010, 06:05:41 pm »
  • Hax ASM
  • Write software
  • ???
  • Profit
Not exactly what I had in mind. What I meant was, are there tile editors that deal with compression? Or do you normally use a tool to extract the data, then use a tile editor on the extracted data, and then use a tool to put the data back in?

When you modify compressed data, it changes in size. What then? Overwrite? Truncate? It would take a pretty smart algorithm to re-point stuff in a generic way that would be widely applicable. So the problem isn't about the compression algorithm. It's about how we shuffle data around.

Personal Projects / Re: SuiteNES - Plug-in based hacking tool
« on: October 27, 2010, 08:01:08 pm »
That's a good question, and it probably warrants a little research. This is actually something I haven't really had to deal with yet. I don't think compression is that common on NES, as far as tiles and text are concerned.

What is the general approach for compressed data? Extract, modify in a suitable editor, and re-insert?

Personal Projects / SuiteNES / Romulus
« on: October 26, 2010, 09:03:18 pm »
SuiteNES is an NES ROM editor. Romulus is a level-editor-framework used by both SuiteNES and its hypothetical plug-ins.

<Additional Photography>

The idea is that SuiteNES is plug-in based. The pattern editor in the screen-shot is a plug-in. (The header and hex editors are the basic editors and are always there.) All the editors open for a ROM are presented in a tabbed interface. You can open multiple ROMs, allowing you to copy/paste between them. You can use the MDI interface, or you can elect to use the document list at the bottom for a tabbed-like-interface. (Mmm... tab hierarchies.)

SuiteNES is a .NET application, which means the plug-ins can be written in VB, C#, C++/CLI, or any other .NET language.

Below is an overview of my plans. I'm using this to sort out my thoughts and commitments as much as to inform others:

Types of plug-ins:
  • ROM data Editors
  • File Editors
  • "File Builders" (e.g. assembler, inserter, etc.)

Planned editors:
  • Header Editor DONE
  • Hex Editor DONE
  • Pattern Editor DONE
  • Palette Editor DONE
  • Assembler EditorDONE

Planned features:
  • Extensible build system. Supports ASM (and command-line utilities) out of the box. Support for additional file-types can be added via plug-ins.
  • Undo/redo system (should the plug-in choose to support it)
  • "Project system" - (Upgraded from possible to planned) This would basically include enhanced versioning features, and the ability for plug-ins to store "session" data. For instance, the hex editor could store the current table file, and the pattern editor could store the layout of patterns opened for editing (or even a list of different layouts). This would allow the user to save a project, and come back later and pick up where he left off. It would also allow him to share the project with others, which would be great for collaboration.
  • Debug output. Either for FCEUX or Nintendulator, or, ideally, both.

Possible features:
  • Disassembler
  • Patcher/Patch maker
  • Rom comparison tool
  • Rom expander (would allow you to specify which banks are moved where to deal with mapper requirements)

Other thoughts:
  • Ideally I would like to add SNES support down the road, but I would need a lot of help with this. I don't have the same kind of intimate knowledge of SNES that I do NES.
  • I'm considering a plug-in gallery sort of feature, like a very simple version of FireFox's "Get Add-Ons".

Personal Projects / Re: Blaster Master Editor
« on: October 12, 2010, 06:13:33 pm »
No. The middle mouse button is used for scrolling (like Editroid, if you've used it). You can also hold down control and use the left mouse button to scroll. I should look into Jigglysaint's suggestion to support the arrow keys as well.

Personal Projects / Re: Blaster Master Editor
« on: October 11, 2010, 05:36:15 pm »
What resolution are you running? Here is the program running on my computer at 800 x 600, and at 640 x 480. I'm guessing that you're running at 640 x 480, otherwise there shouldn't be a problem. If you are running a different resolution, can you post a screenshot?

I can't see myself making 640 x 480 support a priority. I can make it work. I know a lot of people in the rom hacking community have sub-par hardware, but these days 800 x 600 is considered low resolution. The computer my family had over ten years ago ran 800 x 600. Most of the software I use daily doesn't support 640 x 480.

Personal Projects / Blaster Master Editor
« on: October 09, 2010, 01:39:59 pm »
Hey folks. I've got a Blaster Master editor in the works. Pretty much done, really. Think BCK meets Editroid, if you're familiar with the two (or just watch the video on youtube).

Here is version 1.0.

I've been working on an NES level-editor framework that can be used in VB.NET or C# (or any .NET language) to make it easy to slap together a decent editor. What I had in mind was using my framework to make an editor for TMNT in order to test out/refine my framework. To that end, I'm more than willing to make/cooperate on a TMNT editor. (I can also help with the hackinating if necessary.)

ROM Hacking Discussion / Re: Teenage Mutant Ninja nes Turtles level editor
« on: September 29, 2010, 09:24:18 pm »
If someone gets the notes (and the source, if available), I might be willing to slap together a minimal editor, for which I would then release the code in case anybody wanted to elaborate on it.

ROM Hacking Discussion / Re: Teenage Mutant Ninja nes Turtles level editor
« on: September 29, 2010, 05:50:45 pm »
Dan has a "google pages" homepage for his projects, but it just says the editor is under development (no download). All old download links seem to 404 or go to abandoned domains.

Edit: Just for shits and giggles, this is my API in its current state.

I think the best approach is not only something that is abstract enough, but extensible. It has to be easy to customize objects to work in various circumstances. For example, it has to be easy for the framework to be extended to deal with new data structures. Or, in my case (NES), my aim is to make it easy to extend my ROM class by implementing a specific mapper so you don't have to wrestle with pointers.

As far as feasibility, I know that I already have something that I could easily use over and over again to make my life much easier. Would others use it? Probably not, but I could at least post it as some very useful example code others can learn from. If you really want to make it cross platform, that brings us back to extensibility. In your tiles example, rather than programming support for every kind of tile, make it easy to program support for additional types of tiles. The design would need to be very carefully considered, but very doable. If one took this approach, then community would be an important aspect of it. Only one person needs to write code to handle SNES tiles. He can then share it with the community, and everyone can plug it into the framework. With that kind of approach, there is real potential for an incredibly expansive and highly flexible framework.

Even if it was the most awesome framework in the world that could handle 99,99% of all games, barely anyone would use it. The problem is: romhackers love to redesign the wheel. You have to hit most of them over the head with a wrench to get them to use other people's libraries/code. I don't know why this is either...
Hmm... I'm that way, I guess. Especially when it comes to rom hacking, I like to roll my own code instead of using someone else's code. Maybe it's like stroking my ego, proving to myself that I've mastered the material at every level. Or maybe I just want to know my program inside and out the same way I want to know the ROM I'm hacking inside and out.

Huh. I've already started on a project like this. After having made 4 or so NES level editors (in .NET), it finally occurred to me to make a re-usable level-editor framework.

Its a work in progress, currently evolving with the editor I'm making with it. It's got a ways to go, but its still handy in it's current state (I do have an almost-finished level editor for blaster master made with this framework). It's designed to be compilable to a DLL and used in any .NET language. It handles various aspects of making a level editor.

It has classes to handle basic ROM data structures. It can load/edit/compare/save ROM images, deal with pointers and pointer tables, palettes, and load patterns. It also renders screen images in a manner that mimics the NES video hardware (i.e. sprite and bg pattern tables, palettes, name/attribute tables and sprite data).

The framework also has UI features, like a "screen grid" control that displays large game areas and lets the user scroll around (based on Editroid), and a palette editor control.

Unfortunately, it's not very "portable" (i.e. won't work for consoles other than NES). The fact of the matter is that you would have to use different code to deal with ROMs for different hardware. But if anyone is interested in looking at/dicking with/using/expanding upon/collaborating on/etc. the code I can share it.

News Submissions / Re: Utilities: Editroid - A New Metroid Editor
« on: October 02, 2007, 06:24:23 pm »
SnarfBlam, if this editor is anything as good as you say, I will implant a slew of female organs and have your babies.
So, um, yeah. Do remember, though, that we are editing a ROM and it comes with certain built in limitations, and these can be magnified when you are working with a GUI instead of a hex editor. This will become most apparent in the Item Editor and the Structure Editor (though I do expect to have a second release with improvements later down the road), so don't throw your hex editor out just yet. I'm not saying Editroid is full of fail and aids, but don't think it is the Jesus Christ of level editors.

News Submissions / Re: Utilities: Editroid - A New Metroid Editor
« on: September 25, 2007, 06:49:02 pm »
I think a Metedit veteran would have a very easy time picking it up. The main window of Editroid is basically Metedit's main window and map editor tacked together. There are some differences in the details. The biggest difference is in how the special editors (palette/item/others) work. If you've tried to use Metedit's item editor, though, you will probably appreciate Editroid's. It's more complicated but can do alot more.

News Submissions / Re: Utilities: Editroid - A New Metroid Editor
« on: September 20, 2007, 04:42:07 pm »
Most aspects of the editor will be pretty straightforward, but you need some level of understanding as far as the game's map system is involved. Also, you will probably encounter some seemingly inexplicable limitations due to the format of data in the Metroid ROM, and editing items and password data (these features have been added to Editroid since the original post) will probably require a slightly deeper understanding of the game's internals. Perhaps I will write a guide at some point.

Also, as a result of a handful of new features being added, the first release is more likely going to be in October, rather than September.

News Submissions / Re: Utilities: Editroid - A New Metroid Editor
« on: September 05, 2007, 07:00:13 pm »
Editroid currently can't add/remove objects from rooms. Adding new objects would require expanding the ROM and fixing a whole lot of pointers. A more likely implementation in the future might be the ability to add and remove items from rooms without exceeding the original total data size for each level (meaning you would not be able to add more than you have previously removed), but such a feature won't be present in the first release (maybe 1.1). To reiterate the news post, Editroid does not support item editing. If you are familiar with the format for item data and would like to see item editing in future versions (and you name in the credits), by all means, email me ( with the info. I've deciphered 90% of the item data, but without the last 10% it is useless.

A quick comparison of Metedit/Editroid features:
Enemy editing:
    Metedit (can't change if enemies respawn)
Password encoder/decoder:
Item editing:
    Metedit (partial support)
Palette editing:
    Metedit (partial support)
    Editroid (all level palettes)
Structure/combo editing, map creator, physics preview, title text editor:

Pages: 1 ... 18 19 20 21 22 [23]