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

Author Topic: Would a framework designed to handle the ROM interaction in editors be useful?  (Read 5036 times)

Mauron

  • Sr. Member
  • ****
  • Posts: 475
    • View Profile
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:

  • Reading data from the ROM.
  • Writing data to the ROM.
  • Handling pointers.
  • Displaying graphics.
  • Tracking used and free space.
  • Allowing for plugins, to keep everything for a game under one roof.

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?
Mauron wuz here.

Trax

  • Sr. Member
  • ****
  • Posts: 491
    • View Profile
    • Trax ROM Hacking
Framework
« Reply #1 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...

Gemini

  • Hero Member
  • *****
  • Posts: 2007
  • 時を越えよう、そして彼女の元に戻ろう
    • View Profile
    • Apple of Eden
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.
« Last Edit: September 24, 2010, 03:21:01 am by Gemini »
I am the lord, you all know my name, now. I got it all: cash, money, and fame.

KaioShin

  • RHDN Patreon Supporter!
  • Hero Member
  • *****
  • Posts: 5697
    • View Profile
    • The Romhacking Aerie
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...
All my posts are merely personal opinions and not statements of fact, even if they are not explicitly prefixed by "In my opinion", "IMO", "I believe", or similar modifiers. By reading this disclaimer you agree to reply in spirit of these conditions.

Gemini

  • Hero Member
  • *****
  • Posts: 2007
  • 時を越えよう、そして彼女の元に戻ろう
    • View Profile
    • Apple of Eden
It's because of the challenge. It tastes so good. ^0^
I am the lord, you all know my name, now. I got it all: cash, money, and fame.

Mauron

  • Sr. Member
  • ****
  • Posts: 475
    • View Profile
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.
Mauron wuz here.

Gemini

  • Hero Member
  • *****
  • Posts: 2007
  • 時を越えよう、そして彼女の元に戻ろう
    • View Profile
    • Apple of Eden
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.
I am the lord, you all know my name, now. I got it all: cash, money, and fame.

Nightcrawler

  • Hero Member
  • *****
  • Posts: 5748
    • View Profile
    • Nightcrawler's Translation Corporation
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.
TransCorp - Over 20 years of community dedication.
Dual Orb 2, Wozz, Emerald Dragon, Tenshi No Uta, Glory of Heracles IV SFC/SNES Translations

snarfblam

  • Submission Reviewer
  • Hero Member
  • *****
  • Posts: 589
  • CANT HACK METROID
    • View Profile
    • snarfblam
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.

Mauron

  • Sr. Member
  • ****
  • Posts: 475
    • View Profile
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.
Mauron wuz here.

Nightcrawler

  • Hero Member
  • *****
  • Posts: 5748
    • View Profile
    • Nightcrawler's Translation Corporation
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.
TransCorp - Over 20 years of community dedication.
Dual Orb 2, Wozz, Emerald Dragon, Tenshi No Uta, Glory of Heracles IV SFC/SNES Translations

Mauron

  • Sr. Member
  • ****
  • Posts: 475
    • View Profile
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.
Mauron wuz here.

snarfblam

  • Submission Reviewer
  • Hero Member
  • *****
  • Posts: 589
  • CANT HACK METROID
    • View Profile
    • snarfblam
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.
« Last Edit: September 26, 2010, 07:33:33 pm by snarfblam »

SpiderWaffle

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Any new updates with this?  Has anyone heard from snarfblam?  It looks like he updated his website not too long ago in last August.