SMUSE - A community collaborative effort

[Nu Zalem]

I've recently gotten the idea to redraw some sprites in SM, but the task to do so atm is utterly cubersome and inefficient. Other SM hackers are also in the same boat. IMO this needs to be rectified, but I'd like the community as a whole to come together on an "end-all-be-all solution". The following is my idea of how to rectify it:

:: SMUSE - What is it? ::

Super Metroid Universal Sprite Editor or SMUSE is an editor (an idea at the moment) that loads all of the sprites into Super Metroid without the need to use TLP/YY-chr/etc.


:: Coding ::

I haven't decided on a language to use for it per se, but there are plenty of options. I have minimal experience in C, C++/C#, but there's many other languages and I want to let the community come discuss this particular topic further as I want this to be a community project, not just a one-man show (hopefully). In the end, regardless of what the program is written in, it should run efficiently.

:: How would SMUSE theoretically work? ::

One would open the rom like in SMILE and from there you can select which sprite to load whether it be Samus, Ridley, Mother Brain, etc from a dropdown list on a menu (will make a mockup photo of what the program could look like later). Afterward, there would be another dropdown list of which particular sprite you'd like to edit and then you proceed to edit with pen, line, rectangle, circle, fill bucket, and other tools.

:: Palettes ::

Any palette format whether it be tpl, yy-chr, fatilety, etc. can be loaded. Just simply load the palette and you're gravy. You could also edit/save palettes within the program just like you can with SMILE/TLP/YY-Chr. If you select a sprite without loading any palette then the default palette (in the case of Samus, this would be the normal yellow colored "power suit"). Grime had mentioned to me that the program could also preload glowing palettes, spore, fog, acid, rain, title screen, ending credits, other FX1 effects/other graphics. A ton of possibilities can be had here.

:: Benefits ::

The main advantage this editor would have over the other editors is that it can load the sprites in their proper form without needing to spend a ludicrous amount of time searching through the rom or using TLP's tile arranger (ideally all the animation data or whatever data needed will also be preloaded along with this). If ideas presented are implented well enough, TLP/YY-chr could potentially become obsolete as far as editing sprites are concerned. Hackers would save a huge amount of time editing sprites due to all the sprites being automatically arranged when loaded (which makes the process more efficient). This program could possibly be integrated into SMILE (which makes things even simpler), Cheesy (debatable), or be a complete standalone ordeal...it'll just depend on how things progress I suppose.

For now I want to bring this lengthy post to a close and say that I hope that you all read and give some feedback on this. If you have any ideas you'd like to share, if you want to help me make this idea into a reality, etc. then feel free to post. I await your responses. Good day to you all and thanks for your time.

[Power Missile]

Can't wait to see this happen.  It'll be one hell of a program if it's made.  :grin:

[P.JBoy]

First thing to do is decide on the language and make a subversion on Google code

[DSO]

Some of us may have added custom enemies or added new species, so it might be helpful to make the list expandable with custom entries.

[zephyrtronium]

For the language, I recommend either a scripting language, so that custom scripts for loading and saving data could be given, or C, because there are a ton of scripting languages that can be embedded in C programs. Having a scripting language available makes it so that you can write a core for handling files and editing and such, and then you can write different modules in a (garbage collected) scripting language to abstract away all the implementation details. You could also use dynamically linked extensions, but that is much more difficult to make portable (if that's a concern) and to do right. Of course, since most scripting languages are unsuited to raw data manipulation, dynamically linked extensions might be a better approach in the end.  Io looks fairly interesting, however, and there are probably more good ones.

My recommendation would be to write a core in C which handles the user interface, saving, loading, and editing; and which provides an API for Io extensions for graphics, palettes, and tiletables. These extensions would be asked to find editable data (hard-coded, loaded from a list file, or by search), perhaps given information on the particular game being edited if you want to make it support more things than just SM; to convert data from the ROM's internal representation to a standard format; and to convert from that format back into the game's, warning if the new size is larger than the old and possibly giving relocating and repointing options.

[Quietus]

Just having the ability to edit Samus's sprites in a reasonable manner would be worth it alone, let alone the others.  Would this also include non-living things such as the bomb explosion and beams?

Also, FYI, the phrase would be "be all, end all", as opposed to the other way around.  This is where the phrase "thinks he's the bee's knees" comes from.  It was the contraction b's and e's (from Be all and End all) getting butchered. :^_^:

[Mon732]

A little quote of ProjectXVII regarding this topic.

Code Select Expand

ProjectXVIII That some of the sprites are not aligned on an 8x8 grid
ProjectXVIII A notable one is the Ripper
ProjectXVIII Its head is a couple pixels lower than its body.

[Crashtour99]

I'll start off by saying that enemies and enemy projectiles would probably be the easiest way to get it going.
If you had it scan $A0 for enemy header data (it's always in the same format) it could find a ton of relevant data for each enemy (gfx location/size, palette location, AI pointers, etc.).  The hardest part would be searching the AI routines for the starting point of the AI's main table (which contains delays and tilemap pointers, as well as pointers to routines to run).  There are also special gfx enemies to consider, who have their own specially coded hitboxes.  Bosses are also a lot trickier than normal enemies.  Enemy projectiles are essentially the same, but called via the AI (loading the projectile header location) and JSL to $86 (where the projectile's header and AI are located, their tilemaps are in $8D though which has almost zero free space).

It's a great idea, and would really help with creating custom sprites.  I'd love to see this go somewhere.

[Nu Zalem]

Can't wait to see this happen.  It'll be one hell of a program if it's made.  :grin:

I imagine it would be, but it's a ways away from getting off of the ground. First we need to put ideas together and build a foundation. Do you have any ideas, programming knowledge, etc. to help get the ball moving?

First thing to do is decide on the language and make a subversion on Google code

I agree. I'm not sure which language would eventually be decided but this is one of the first steps that I'd personally like dealt with sooner rather than later. Some people here are proficient with Python/C/C++, and I think Black Falcon is proficient with Delphi. Others are proficient with ASM but that's about all I know concerning the community as a whole. If it were simply up to me I'd probably go with either C or C++, but again, I want the community as a whole to get involved here.

Some of us may have added custom enemies or added new species, so it might be helpful to make the list expandable with custom entries.

That's a good idea and definitely something to keep in mind once I or a number of us start to actually code this baby. One step at a time though.

For the language, I recommend either a scripting language, so that custom scripts for loading and saving data could be given, or C, because there are a ton of scripting languages that can be embedded in C programs. Having a scripting language available makes it so that you can write a core for handling files and editing and such, and then you can write different modules in a (garbage collected) scripting language to abstract away all the implementation details. You could also use dynamically linked extensions, but that is much more difficult to make portable (if that's a concern) and to do right. Of course, since most scripting languages are unsuited to raw data manipulation, dynamically linked extensions might be a better approach in the end.  Io looks fairly interesting, however, and there are probably more good ones.

My recommendation would be to write a core in C which handles the user interface, saving, loading, and editing; and which provides an API for Io extensions for graphics, palettes, and tiletables. These extensions would be asked to find editable data (hard-coded, loaded from a list file, or by search), perhaps given information on the particular game being edited if you want to make it support more things than just SM; to convert data from the ROM's internal representation to a standard format; and to convert from that format back into the game's, warning if the new size is larger than the old and possibly giving relocating and repointing options.

Makes a lot of sense and I had considered using C from the start when brainstorming this (before I made the topic). I'll be sure to speak to you further regarding such.

Just having the ability to edit Samus's sprites in a reasonable manner would be worth it alone, let alone the others.  Would this also include non-living things such as the bomb explosion and beams?

Personally, I don't see why it wouldn't. May as well add it to the list since we're still discussing ideas and such.

I'll start off by saying that enemies and enemy projectiles would probably be the easiest way to get it going.
If you had it scan $A0 for enemy header data (it's always in the same format) it could find a ton of relevant data for each enemy (gfx location/size, palette location, AI pointers, etc.).  The hardest part would be searching the AI routines for the starting point of the AI's main table (which contains delays and tilemap pointers, as well as pointers to routines to run).  There are also special gfx enemies to consider, who have their own specially coded hitboxes.  Bosses are also a lot trickier than normal enemies.  Enemy projectiles are essentially the same, but called via the AI (loading the projectile header location) and JSL to $86 (where the projectile's header and AI are located, their tilemaps are in $8D though which has almost zero free space).

Now this I wasn't exactly too keen on but thanks for letting me know. The knowledge you, Scyzer, Black Falcon, DSO, and others proficient with ASM could prove to be quite instrumental here.

All in all, thanks for the quick responses, I hope to see much more feedback *looking at the rest of Metconst*. This evening I'll take some time discussing what language and such to use with those in IRC and I'll keep my eye on the thread here.

[Charmander106]

I would like to give some ideas for the built-in graphic editor. I use YY-Chr as my graphic editor of choice, but a mixture of TLP and YY-Chr would be cool. The way you edit the graphics in YY-Chr and the Tile Arranger in TLP could make SMUSE's graphics editor the best of both TLP and YY-Chr. The tools in the editor can have your basic tools like the pencil, paint bucket, line tool, square tool, circle tool, etc. But I would like a select tool where you can switch between the shape like a square or circle and a polygon tool similar to the one in photoshop. What would also be cool it the ability to rotate a selected region any degrees.

This is all for now. More will come later if I can think of anymore...

[Nu Zalem]

I use YY-Chr as my graphic editor of choice, but a mixture of TLP and YY-Chr would be cool.

SMUSE will hopefully surpass TLP/YY-chr completely. I have considered adding an option to edit area graphics (Crateria tiles for example) as well (you'll still need SMILE or Cheesie[should it ever get finished] to edit levels).

The way you edit the graphics in YY-Chr and the Tile Arranger in TLP

Editing may or may not be similar to YY-Chr/TLP, but SMUSE should automatically load/arrange sprites for you. That's one of its main purposes.

But I would like a select tool where you can switch between the shape like a square or circle and a polygon tool similar to the one in photoshop. What would also be cool it the ability to rotate a selected region any degrees.

As things get off the ground and going I'll consider implementing this or seeing if it would be possible/feasible. I'm no miracle worker though. Thanks for the ideas, keep them coming.

-------------------------------------------

Here's what I have decided/come up with so far:

Coding - The program will be coded in C with Lua (for scripting)

Palettes - You can either make your palettes by hand (if you prefer the old fashioned way) or use a tool like Photoshop/GIMP/etc. to make your palette and such. You can modify the glowing palettes  Heat Glow on Samus' armor for example) in Photoshop/GIMP/etc. via saturation and such too.

Custom entries - I'd like there to be custom entires (at least as many as possible). I just have little to no idea how to go about implementing it at the moment. It'll be a learning phase for me.

[Qactis]

Okay so:


[spoiler=First off]Fantastic idea. Based SOLELY on the idea that a program could grab SM's left-to-right top-to-bottom arrangement of sprites and form whole images on a table for editing, and then import them back into the ROM makes the ENTIRE idea worth going for.[/spoiler]
[spoiler=Coding]It sounds like this program would have to account for the size of every graphic in the game, and somehow limit you when you are editing the sprites, so as to prevent you from importing an image that is larger (in height/width or actual pixel data) than the version you exported, which would overwrite data in the ROM. That sounds extremely tedious and difficult.[/spoiler]
[spoiler=Palettes]A smart editor would know where to grab the palette data in the ROM for the sprites (I haven't done much ASM work with enemies in SM, but I'm pretty sure that palette data looks the same for every enemy, and I know it does for PLMs (grab specific colors from the compressed area gfx set palette). I would recommend a good GUI for displaying the palette for the sprite (like our favorite tile editors), and a popup option when you [right-click?] a color in the palette which would allow you to edit the palette on the fly, I'm guessing would be the same as SMILE's 00-1F range, which isn't too many colors, so not impossible to code.[/spoiler]
[spoiler=GUI]I'm not the pickiest in the world about GUIs, since most people that make hacking utilities don't even make one, I'm not one to complain. Undo and Redo having a long record (like 20 steps) would be sweet. YY-CHR is my favorite tile editor but I know most prefer TLP for some reason. Definitely would be nice to see lots of brush tools, hotkey copy/cut/paste, including being able to select pixels in an area or with a lasso-type tool and being able to copy/cut/paste selections. I noticed someone mentioned being able to rotate the image. There is a program out there called RotSprite which can rotate sprites quite nicely. I'd leave it to that. Having an editor window that can animate the sprite for you to see what it looks like in action, and let you go backwards and forwards through the animations step by step would be sick.[/spoiler]
[spoiler=Source]Make it open! :DDD[/spoiler]

I don't have anything else to add because I don't know any high-level programming languages yet

[zephyrtronium]

Coding - The program will be coded in C with Lua (for scripting)

I looked at Lua first, but discounted it when I saw that it has a unified type for both integers and floating-point numbers. There are a lot of operations on integers that Lua does not support but are critical in manipulating data for these types of things. If you want a language that looks similar to (and is heavily inspired by) Lua, go with Squirrel.

I have to go to work now, but today I'll think up an example API that would allow nearly complete generality in basically everything, as well as what all would be necessary within the core to pull it off.

[Nu Zalem]

Coding - The program will be coded in C with Lua (for scripting)

I looked at Lua first, but discounted it when I saw that it has a unified type for both integers and floating-point numbers. There are a lot of operations on integers that Lua does not support but are critical in manipulating data for these types of things. If you want a language that looks similar to (and is heavily inspired by) Lua, go with Squirrel.

I have to go to work now, but today I'll think up an example API that would allow nearly complete generality in basically everything, as well as what all would be necessary within the core to pull it off.

Squirrel eh? Never even heard of that language until tonight. We learn something new everyday eh? Well I'm looking into it...seems similar to C/C++ from what I can see so far. I await your return from work via IRC or post in here.

[snarfblam]

Huh. Funny how there was no interest in this when I looked into the same exact idea. Maybe it was the presentation...

Anyways, if you're still picking a language, I would recommend you consider C#. It's possible (and easy) to support scripting (in a variety of languages) and plugins if you want your C# program to be extendable. C# also has a built-in library that can't be beat. The other advantage of C# is that I could offer some coding assistance :D

[Nu Zalem]

Considering I haven't completely mapped out everything/have no idea how to start yet I'll consider it (I have a C# book on my shelf). Now I'm kinda torn...

[P.JBoy]

I don't think it would be too difficult to write this in multiple languages, we'd have to compile them separately and link them afterwards is all

[snarfblam]

Depending on how you mean that, I don't think it would be worth the confusion. If you wrote the main executable in a single .NET language, many languages could be supported for extensibility without trouble, but if you're talking about trying to write parts of the main executable in different languages and linking them together, that sounds like it would make for a very nasty and confusing debugging experience.

[Crashtour99]

Thanks to some documentation from Black Falcon, I now have a pretty decent understanding of how Samus animates (and how to find the gfx offsets for each pose and animation frame, as well as tilemaps, etc.).

Nuz, if this is still a thing you're interested in doing, feel free to shoot me a line and we can chat about the stuff I learned.

[Quietus]

Let's hope so.  Then we can all drown in a torrent of shoddy Samus edits. :^_^:

[A_red_monk_called_Key]

Nu Zalem i also have some data on the subject(incomplete) if needed.

[Damski]

Nu zalem was last time online in july.. I beliveve this project is death unless someone else to continue this project.

[Crashtour99]

He's on here occasionally.  IRC as well.  In fact, I just spoke with him last night about some of this stuff.   :wink:

[Damski]

He's on here occasionally.  IRC as well.  In fact, I just spoke with him last night about some of this stuff.   :wink:

AH I see my bad then xD