Author
|
Topic: Screenshots (Read 67894 times)
|
Vanya
Guest
|
 |
« Reply #1995 on: October 15, 2010, 04:22:37 pm » |
|
<pic>
This is an every-NES-ROM-editor. It isn't much yet, but a big point of it is plug-in support. (I'm seriously considering releasing any future level editors as plug-ins, including my Blaster Master editor.) The pattern editor is a (very incomplete) plug-in, just to show I've actually got something going besides hot air. Anyone would be able to program a plug-in in C#, VB.NET, or any other .NET language. (Also I know I'm showing the wrong mapper for Zelda. I've already fixed this.)
That's a really awesome idea whose time is way over due. And, incidentally, if you or anyone ever makes a level editor plug-in for Castlevania that actually allows comprehensive room rearrangement I will love you/them 4evar! |
|
|
|
|
tcaudilllg
Guest
|
|
« Reply #1996 on: October 20, 2010, 05:05:02 pm » |
|
Yes I agree 100%: a generic ROM editor is definitely needed.
|
|
|
|
|
RadioShadow
Guest
|
|
« Reply #1997 on: October 23, 2010, 05:54:52 pm » |
|
Cool, I'll be able to play it in English!  I've been working on a "Advance wars: Days of Ruin - Map Header Editor":  That "  " data from what I can tell does nothing. I think it was just a note to the developers on if the map is from the previous AW games or not. Some have "04" which seems to be on maps from previous games. Campaign maps use the value "01" and some previous "War Room" maps like "Lands End". "00" is set for most of the new maps. |
|
|
|
|
PolishedTurd
Guest
|
|
« Reply #1998 on: October 23, 2010, 06:01:16 pm » |
|
Yes I agree 100%: a generic ROM editor is definitely needed.
What is the advantage of a generic ROM editor? What would it allow people to do that is currently not possible or much more difficult because of the tools available? Can someone give an example? |
|
|
|
|
snarfblam
Guest
|
|
« Reply #1999 on: October 23, 2010, 07:32:01 pm » |
|
The central idea is that it is plug-in based. This doesn't seem like a huge advantage in and of itself. What would it matter whether somebody's utility runs as a standalone program versus inside another program?
One advantage is that plug-ins can collaborate. Say you make a level editor plug-in. Now say you want to let the player edit text for a character or screen or whatever. You can have a button to edit said text, which simply loads up the hex editor with the appropriate table file. Or you can pull up the (hypothetical, but planned) palette editor to edit the level's palette. The palette editor can export the current palette to the pattern editor.
You can use the editors in conjunction with each other, should your situation warrant it. Any changes made in one editor will show up in another. You can edit tiles, switch over to a level editor, and viola, the level editor shows the changed tiles. Needing to save in one program and re-open (and re-find your place) in another program is a pain.
Any feature built into the program is essentially built into every plug-in. Your recent file history, boiler-plate UI, versioning/backup, save-and-play, and so on, are all free with no effort.
So, to me (a programmer) there are some big benefits. For the end user there are, at least, a lot of conveniences. I don't think generic is actually a great way to describe it. Generic implies it works okay for most things and great for nothing. A better way to put it would be specializable and extendable. All the different parts can work together and every programmer has access to the expandable library of features.
|
|
|
|
|
BlackTelomeres
Guest
|
|
« Reply #2000 on: October 24, 2010, 07:54:03 pm » |
|
In addition, I imagine that the time saved for developers by the generic features in the program could be a significant help in getting releases out faster due to reduced workload.
|
|
|
|
|
Trax
Guest
|
|
« Reply #2001 on: October 25, 2010, 04:36:47 pm » |
|
The project in itself is cool, but personally, I don't see such big an hassle in doing a few copy-paste or importing a few objects for the most common routines, like tile loading or hex convertions. I think most programmers already have their own library ready to go when they start a new project...
|
|
|
|
|
snarfblam
Guest
|
|
« Reply #2002 on: October 25, 2010, 05:50:01 pm » |
|
For what it's worth, if somebody did choose to write a plug-in, he wouldn't need to use my UI classes or my graphics-loading classes, if it doesn't suit him. There's more involved than a code library, though. There's also the aspect of a common ground that allows tools to inter-operate smoothly, and the convenience of having it all in one place. Like I said before, it's just irritating when you need to use more than one tool and you find yourself having to save, switch programs, re-open and find your place, over and over again. (That's not the only problem I'm trying to address, though.)
Some people aren't going to see the draw. That's fine. Honestly, I'm not expecting a plethora of plug-ins to burst onto the scene when I release this tool. I don't expect it to become the de-facto hacking standard. But it strikes me as something worth trying.
|
|
|
|
|
Trax
Guest
|
|
« Reply #2003 on: October 26, 2010, 01:00:43 am » |
|
I understand what you mean, except maybe for the part where you say you have to "re-open" something. I'm not sure what it refers to. If you open a file, modify it and save, you don't have to close the program to try the ROM. For the rest, I will always be slighty biased only because I'm on a Mac and I code in Objective-C under the Cocoa library...
|
|
|
|
|
snarfblam
Guest
|
|
« Reply #2004 on: October 26, 2010, 05:17:14 pm » |
|
I understand what you mean, except maybe for the part where you say you have to "re-open" something. Suppose I'm using two programs at the same time for the same ROM. I'm using a level editor and a tile editor. There can be a little back and fourth. Say I want to edit a level. Fire up the level editor, open my ROM, and go to the room I'd like to edit. I need to draw a few new tiles. I need to save in the level editor, first. Open the tile editor, open the ROM, and find the actual tiles I need to edit. I edit some tiles, then save. Now I'm ready to go back to the level editor. But before I can continue, I need to close and re-open the ROM, because I've made changes with an external program, and if I don't re-open the ROM, I'll save over those changes. So I re-open the ROM, and go back to the area I was editing. Finish my room, move on to the next room, and, oops, I need to draw another tile. Save. Go back to the tile editor, close and re-open the ROM, scroll way back down to find the tiles I'm editing. Make my changes. Save. Switch back to the level editor. Re-open. Go back where I left off. All that process is because there were two instances where I wanted to draw a new tile or two. I don't think that I'm the only one whose run into this. (Am I?) |
|
|
|
|
Trax
Guest
|
|
« Reply #2005 on: October 26, 2010, 09:27:06 pm » |
|
Yeah, I understand what you mean, and it's perfectly legit. I always store the entire ROM to a Data Object in RAM in all my editors, so yeah, if you have two editors for the same game, you would end up overwriting whatever version of the ROM in RAM with the last save. Maybe that's why I always strive to have one editor for a game that can edit as much of the game's features as possible...
Anyways, SuiteNES looks like a cool project. Keep up the good work...
|
|
|
|
|
Seeeeph
Guest
|
|
« Reply #2006 on: October 31, 2010, 03:26:24 pm » |
|
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #2007 on: October 31, 2010, 03:29:12 pm » |
|
 If it plays even half as good as it looks: :thumbsup:
|
|
|
|
|
Gideon Zhi
Guest
|
|
« Reply #2008 on: October 31, 2010, 06:34:17 pm » |
|
My only concern is the dirt path. It really looks kind of out-of-place in a futuristic space colony.
|
|
|
|
|
Neil
Guest
|
|
« Reply #2009 on: October 31, 2010, 06:40:16 pm » |
|
Maybe in the future there is no Miracle Grow.
|
|
|
|
|
|
