Seems like a good initiative, but I doubt it would be worth the effort. Yes, there are functions that are used often and the same over games of the same platform, but I don't think there is enough common ground to justifiy an entire framework. According to my own experience, only the tile creation methods are truly the same for every editor I made. Maybe a few convenience functions, like converting a hex string to a int (and vice-versa). Aside from that, structures are always different...

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...

Trax: I think that there's enough for something, but you may be right. I'm going to keep developing my editor with this in mind, and then experiment with it when I'm done.

Gemini: That's the general idea I had, with a different purpose, and about the same origin. I just started organizing the data I had, and it started becoming a more advanced tool.

KaioShin: The fatal flaw. I tend to be the same way. Not 100% discouraged yet though. At the very least, I'll have something for my next project.

I generally share the same opinion as Trax. Much of ROM Hacking is so game specific, I'm not sure you'll find enough commonality to make it worthwhile.

Much of what Gemini describes, while useful for C++, is already covered with the .NET framework out of the box.

What's left is the ROM hacking specific functionality. We've got some things such as handling tile data in various formats for older consoles, TIM for PSX, and whatever might be necessary for platforms I don't follow closely. Dumping and Insertion functionality. Table library. Maybe a compression library. We have a serious lack of library for doing anything sound/musical related on nearly any platform. Some code for handling virtual file systems and dealing with isos. Address/Offset conversions. Header functions for those consoles that use them. Those kinds of things.

So, there is some ground to cover, but if you're delving into all those areas, you'll do everything on par, but nothing great. A dedicated tile editor, script dumper, sound utility, vfs utility, that's fully developed and expanded with code would likely be much more useful than some framework code for dealing with a little bit of what they do. It's also unrealistic to really have framework code covering all the things I mentioned well. That's too large a project for one. Although maybe you could pick up some more developers as you go.

I don't want to discourage new creations at all. It might be worthwhile to you and/or others. Just in my opinion, I can't say I think it would be that useful or worthwhile. I have found it difficult to find a lot of reuse for my own code from project to project. You really need to get that design and abstraction level very high and broad to end up being useful from game to game. And when all the work is put in to get there, you probably could have just done the specifics for projects several times over!

My advice to you would be this: Start on paper. Start writing out a design plan and framework hierarchy. Figure out the design and outline of what you intend to do. When you've got something, people can probably give you some feedback. I think this would be a very ambitious project to do right and be useful.

Nightcrawler: You're probably right that things will come out on par instead of great, but I think that would still work for my purposes. I don't expect my idea to become the base for the next Tile Molester or similar program - I want this to be for the next Temporal Flux or Lunar Magic - where on par for some parts is probably enough. For example, I'm working with Ogre Battle right now. If I find the map data, I can either render it from a previously extracted graphic, or build the graphic from the ROM. Obviously one has a distinct advantage if you do it right.

snarfblam: I'm very interested in your project. It sounds like you're a little ahead of me, but since we're not competing with our ideas (SNES vs. NES), that's a benefit if anything.

I'll PM you with a few questions.

Nightcrawler: I need to stress something with you. I realize you are trying to help by rationalizing the difficulty and give constructive feedback based on that, I know myself well enough that I can tell you that it might not be received that way. I can already feel myself wanting "make your idea".

Consciously I realize that's not at all what you're doing, but when I choose to hack a game, I feel I'm approaching a challenge, sometimes with a high difficultly level, and sometimes beyond what I know at the time. While I realize it's not your intent, you may inadvertently get me to a point where I have to abandon the project because it's too much (Going up in an idea is easy for me, going down, not so much).

If you want to help the most, provide your knowledge on what I might need for this type of project. At worst, it's the overly complex system I'll use for the Ogre Battle editor I'm working on now. At best, it will somehow become a new standard in editor development (Yeah right). In the end, it will probably be something I use, and maybe a few others do too.

I want to stress that I appreciate what you've tried to do to help, and thank you for that.

Any new updates with this?  Has anyone heard from snarfblam?  It looks like he updated his website not too long ago in last August.