Romhacking.net

Romhacking => ROM Hacking Discussion => Topic started by: Mauron on September 24, 2010, 01:38:51 am

Title: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Mauron on September 24, 2010, 01:38:51 am
Every game on a system has a lot in common. At the simplest level, the data is the same (bytes and integers and strings, oh my). Even at higher levels, we have similarities.

What if someone (me) made a framework that could handle the things any editor might need, and provided it to the community as a framework? I was thinking of providing the following:


I've begun making something along these lines for the editor I'm developing now - The real question is it worth releasing as a separate entity? It's for the SNES, and developed in a .Net language (C# is my choice, but if the dlls are distributed, any .Net language could use them).

What are everyone's thoughts?
Title: Framework
Post by: Trax on September 24, 2010, 01:59:13 am
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...
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Gemini on September 24, 2010, 03:10:35 am
I have already developed a similar framework, or rather a C++ library that does most of the anal work for you in a simple manner. It was initially developed to handle only image objects (BMP, PNG, TIM) for my Red Moon project, but then it has been expanded to also provide unicode access and conversion, string manipulation, support for the ISO9660 standard (wip), base64, xml, a generic text dump class, etc... Result? Now I have a flexible library that can be injected in pretty much any editor or program I want it to belong to, and it sure makes things a lot easier to do, even stuff that it wasn't even intended for.

The most recent version of the library can be found here (http://gemini.aerdan.org/upload/glib_full.rar).
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: KaioShin on September 24, 2010, 03:26:54 am
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...
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Gemini on September 24, 2010, 03:29:20 am
It's because of the challenge. It tastes so good. ^0^
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Mauron on September 24, 2010, 03:36:50 am
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.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Gemini on September 24, 2010, 05:24:59 am
As long as you keep the GUI and the hacking code separate, it should be a lot more usable than the general package of sources. Flexibility and reutilization are the key.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Nightcrawler on September 24, 2010, 08:45:49 am
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. :P

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.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: snarfblam on September 24, 2010, 10:12:43 pm
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.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Mauron on September 25, 2010, 12:03:50 am
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.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Nightcrawler on September 25, 2010, 10:32:52 am
I forgot to mention, not only is is game specific, but platform/console specific as has been pointed out here. So, again, I think to be really useful, you need to abstract it to a level that would be applicable to many platforms. It should be possible to do, but the further up the ladder you go, the more complex the design becomes and amount of code probably goes up. It's 'easy' to make something that manipulates just NES 2bpp tiles for example. It's more difficult to make something that can handle any tiles. However, it would be far more useful. If you want to make something as useful as possible, I'd recommend approaching it from a very high abstraction level.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: Mauron on September 25, 2010, 01:04:04 pm
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.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: snarfblam on September 25, 2010, 03:24:31 pm
Edit: Just for shits and giggles, this is my API in its current state (http://snarfblam.com/RomulusDoc/classes.html).

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.
Title: Re: Would a framework designed to handle the ROM interaction in editors be useful?
Post by: SpiderWaffle on November 24, 2011, 03:29:10 pm
Any new updates with this?  Has anyone heard from snarfblam?  It looks like he updated his website not too long ago in last August.