+  RHDN Forum Archive
|-+  Romhacking
| |-+  General Romhacking
| | |-+  Mototile - Flexible Metatile Editor
Pages: [1]
Author Topic: Mototile - Flexible Metatile Editor  (Read 1 times)
Karatorian
Guest
« on: May 07, 2008, 05:44:00 am »
Based on some discussion over in this thread, I decided to create a flexible metatile and sprite frame editor. While it's still a work in progress, I decided to release a teaser screenshot and generally announce the project.

The obligatory screen shot (click for fullsize version):



Features currently implimented are:

  • Simple XML based specification files that tell the editor where in the ROM the data is.
  • NES format graphics loading and display.
  • Most of the graphical user interface.
  • Metatile selection and viewing.
  • Row by row and column by column metatile arangements.
  • Metatile editing backend.
  • Basic spec file for Super Mario Bros.

Features on the to do list are:

  • Metatile editing user interface. (The backend's not much good without it.)
  • Pallet support.
  • Proper error handling on IO errors.
  • Confirmation dialogs on close, quit, etc.
  • Preferences loading, saving, and editing.
  • Support for formats other than NES.
  • Support for display of horizontally or vertically flipped tiles.
  • Variable zoom levels for the metatile editor and tileset selector widgets.
  • Help beyond just About.
  • Fixes for various non-critical but annoying bugs.
  • UI layout tweaking.
  • Spec files for other popular games.
  • Other stuff I'm sure I've forgotten...

So anyway, that's what I've been up to the last couple of days. Hopefully I can get a beta release made within a week or so.

In the mean time, please feel free to give suggestions for features, critique my user interface, beg for a release, etc.
frantik
Guest
« Reply #1 on: May 07, 2008, 03:43:47 pm »
 :woot!:

edit: just a UI suggestion:
it would be cool if when you're editing the metatiles you could either:

- type in the metatile number, press tab and be able to enter the next tile number, etc
- be able to click on the main tile grid and select a new tile
- be able to roll the mouse wheel and rotate thru the tiles
« Last Edit: May 07, 2008, 04:53:36 pm by frantik »
DarthNemesis
Guest
« Reply #2 on: May 07, 2008, 11:40:05 pm »
A couple of questions:

1) Is this only for Mac?
2) Will it support variable-size tiles (i.e. not be limited to 8x8)?
BRPXQZME
Guest
« Reply #3 on: May 07, 2008, 11:47:05 pm »
That’s not a Mac screenshot, just a Mac theme.
frantik
Guest
« Reply #4 on: May 07, 2008, 11:49:58 pm »
i assume it's in python so it can be compiled on multiple systems
Karatorian
Guest
« Reply #5 on: May 08, 2008, 06:31:43 pm »
Quote from: frantik on May 07, 2008, 03:43:47 pm
it would be cool if when you're editing the metatiles you could either:

- type in the metatile number, press tab and be able to enter the next tile number, etc

I intend to include some sort of widget where you can type in tile numbers manually. The tab order would be such that you could move from one tile to the next.

Quote
- be able to click on the main tile grid and select a new tile

Point and click tile editing will be supported.

Quote
- be able to roll the mouse wheel and rotate thru the tiles

I didn't think of that. Thanks for the suggestion, I'll see what I can do.

Quote from: DarthNemesis on May 07, 2008, 11:40:05 pm
1) Is this only for Mac?

No. As BRPXQZME said, that screenshot's not on a Mac. It's written in Python using the GTK UI toolkit and should be reasonably portable. When I do a release, I'll proabably release three packages: A Win32 standalone binary, a Linux standalone binary, and a (cross-platform) source package.

Quote
2) Will it support variable-size tiles (i.e. not be limited to 8x8)?

Yes. I assume that adding support for other platforms is going to require other tile sizes and intend to do so. At the moment it only supports NES and 8x8 tiles and it's likely the first beta release will as well.
frantik
Guest
« Reply #6 on: May 08, 2008, 06:53:12 pm »
8x8?  Mario is 4 tiles high by 2 wide for 8 total tiles...

ideally it should be definable in the XML because mario sprites are 8 tiles (4x2) but most enemy sprites in SMB are 6 tiles (3x2), and background tiles are 2x2.  it looks like there's room for sprites up to 4x4 on your current layout..
DarthNemesis
Guest
« Reply #7 on: May 08, 2008, 06:56:14 pm »
Quote from: frantik on May 08, 2008, 06:53:12 pm
8x8?  Mario is 4 tiles high by 2 wide for 8 total tiles...
We're talking about the size of each tile - 8x8 pixels.

Quote from: Karatorian on May 08, 2008, 06:31:43 pm
It's written in Python using the GTK UI toolkit and should be reasonably portable. When I do a release, I'll proabably release three packages: A Win32 standalone binary, a Linux standalone binary, and a (cross-platform) source package.
Excellent, I'm looking forward to this.
frantik
Guest
« Reply #8 on: May 08, 2008, 07:06:28 pm »
Quote from: DarthNemesis on May 08, 2008, 06:56:14 pm
Quote from: frantik on May 08, 2008, 06:53:12 pm
8x8?  Mario is 4 tiles high by 2 wide for 8 total tiles...
We're talking about the size of each tile - 8x8 pixels.

oh, dur lol
Karatorian
Guest
« Reply #9 on: May 08, 2008, 08:11:17 pm »
Quote from: frantik on May 08, 2008, 06:53:12 pm
ideally it should be definable in the XML because mario sprites are 8 tiles (4x2) but most enemy sprites in SMB are 6 tiles (3x2), and background tiles are 2x2.  it looks like there's room for sprites up to 4x4 on your current layout..

Yeah, we where talking about the pixel size of the tiles themselves.

However, you do bring up a good point. Currently, the size of the metailes are defined in the XML, so smaller tiles like the (SMB) block metailes and the enemy sprites have less tiles. The current GUI is hard coded at 2x4 and ignores the tiles it doesn't use. The reason it displays so wide is a bug in some of my GUI stuff.

(Despite all the programming I've done, I've never really written a standard GUI app. It's all either been command line stuff (I'm a un*x hacker at heart) or game stuff with a scratch-built custom user interface. It's been a learning experiance.)

It's intended that such hardcoded limits will be removed from the final program and that the metatile display IU will dynamicly resize to support the required number of tiles. However, some sort of limit will be required to avoid some problems. Due to the dynamic nature of Python, memory allocation and whatnot wouldn't be an issue, so I can support arbitrarily large metatiles, but that creates potential for abuses. (For example, if someone created a spec file with abnoxiously large sizes, the memory allocation could exceed that availble and would likely crash the program or slow the entire system down. The worst case senario, hopefully avoided on modern OSs would be to crash the box.)

In light of this, I'll proably have no hardcoded limits, but allow the user to configure the max sizes allowed in the preferences. I'm thinking that a max metatiles size of 16x16 tiles is a reasonable default for most types of games, but I see no reason to restirct it if someone decides they need more. (Some fighting games, for example, probably have very large frames.)
DarthNemesis
Guest
« Reply #10 on: May 08, 2008, 08:28:13 pm »
Background images could take up the entire screen - for the game I'm working on, 32x24. Having it be configurable sounds like the ideal solution. Smiley
Karatorian
Guest
« Reply #11 on: May 08, 2008, 08:52:12 pm »
I hadn't even though about background images. That's a good point. The great thing about flexible tools is that they can be used for so many things.

Thanks for all the feedback.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC