[SM] SPARTA: Samus Palette, Art & Repoint Tool App (formerly Super Munchtroid)

[Munchy]

a comprehensive editor for Samus

REQUIRES UNHEADERED SMC! WILL NOT WORK WITH PAL!

github:
https://github.com/munchyMouth/super-munchtroid

- LINUX: Super Munchtroid-linux-x64 2.30.0
- WINDOWS: Super Munchtroid-win32-x64 2.30.0

documentation:
Manual (2.29.0 Version)

Installation:

No installation required, simply execute as follows:

WINDOWS (Requires Windows 10)
simply download, unzip and double-click on the .exe

LINUX (Tested on Ubuntu 16)
Download, unzip, navigate to the file directory in terminal and type the following within it

Code Select Expand


./SPARTA


2.30 Features:
- various bug fixes to repointing tool
- PC addresses exposed in repointing tool for tilemap
- additional special poses to cover low health tilemaps(!) and wall jump space jump/screw attack poses

2.29.0 Features
- beam cursor management for sparks and beams
- overhauled palette controls and palette menu bug fixes
- the SPARTA Repointing Tool
- missile fin coordinate menu

2.20.2 Features
- arrow key control of vram (while focused)
- rotate 90° control for editor
- switching off/on beam controls with buttons
- better confirm dialogs
- fixed palette undo
- added ctrl + up | down to navigate poses globally
- shortcut ctrl + o to open files

2.18.0 Features
- project renamed "SPARTA" :P
- support for setting beam offsets
- collapsible panels for sprite manager & beam editor
- added help modal and events
- some general code tidying (under the hood stuff)

2.16.2 Features
- ctrl+left/right events matched up to frame inc/dec
- ctrl+shift+s setup for doing save to sprites and vram
- added help [F1] modal and associated events

2.15.0 Features
- pixel-flip support added
- added variably colored sprite masks
- added palette copy/paste
- added shortcut for show/hide settings

2.12.0 features:
- Some bug fixes around the palette dropdown
- The crystal flash palette
- Conventional key commands for Editor copy/paste/undo/redo/save-tile actions

2.10.0 features:
- Fixed saving sprite bug
- Added 16x16 pixel editing mode
- Added pixel-shifting tools
- modified editor zoom and the menu that accompanies it.

2.6.1 features:
- special poses
- a search bar
- significant bug/palette fixes
- frame by frame loading (ergo, massive performance boost)

Metroid Construction Resource:
http://metroidconstruction.com/resource.php?id=399

Tutorials:
Main Video Tutorial
Video Tutorial

2.10.0 Feature update rundown (sorry for terrible sound quality)
Explains how to fix the "Samus Loading" animation bug (where her lightning bolt is mirrored)
2.10.0 Update

[Munchy]

Progress 11/3

• electron project setup
• tile table created
• byte reader setup

[Munchy]

11/3

Found the offset for the tile data in the stream reader, built a map object to help translate back and forth between. As it turns out, the offset is different to the pc address. Not sure why (ooooh, unless it's that my test file hasn't had the header taken off... I'll check).

[EDIT]. nooop. It's unheadered alright.  I get it now, the value is actually DEA00 * 2, which makes sense given the 2 char of hex needed per byte! confusion over :) this project is racing along!

[Munchy]

12/3

I'll let this image do the talking. Look at the leg and then look at the table.  every pixel of samus' leg maps to every one of the sets of 4s.  thus, you can see that they kinda look the same (0000 is the blue background palette color)!  Why this matters is because this gives me a means to map this data into any visual format I like. Thus, once I cross ref the palette data, I'll start posting some early screenshots of the actual tool!



[EDIT] additional efficiency gains, the entire algorithm only performs data conversion now when it needs to rather than appealing to the readability desired by puny humans.

[Munchy]

13/03

First BIG step made. palette files were easy-peasy to translate, so without any further ado, here's the first tile table completely loaded from an SMC into a modern UI :) It's already clickable so the copy/past aspect will be painless! I'm actually getting kinda tempted to scale it into a full blow metroid sprite editor!



p.s. performance-wise the whole table renders in about a 3rd of a second, so I think we're good!

[Sirkura]

I'm looking forward to this tool the possibilities that open up are substantial for customized mods. So far your progress looks quite promising. I'm definitely keeping an eye on this thread. Also I found the editor i was talking about in my last post. it's source code is also available, it may be useful so i'll drop it here

https://jsm.ostehovel.com/

[Smiley]

This looks promising. Maybe I don't need to make a generic sprite editor myself after all. :grin:

[Munchy]

15/03

I've been working on all the boring file-wiring stuff this last couple of days. It's getting pretty stable now to load in a huge variety of sizes and supports .gfx, .sfc and .smc.  you can now choose your .tpl file as well (though, I haven't baked in support for having it load more than the first table of palettes from the TPL, I might add that at some point though it isn't high up my list of priorities since this is really about getting samus' tiles in order more than anything else).  I've added the ability to precisely specify offsets to load from your file too.  Here's a screen shot.  So the next big thing is getting the "copy/paste" stuff nailed. shouldn't be too tricky.  Hopefully I'll get something in order by next week!

[Munchy]

I've been thinking hard on whether this wants to be a full blown sprite editor. My feeling is, by design, it would have its limitations. The aim was to write something quick and robust. Because of how it renders stuff at the moment, Itd be tricky to manage palette editing. I'd effectively need to write a different render engine to make it perform that kind of stuff quickly. It's probably better as a tool to build easy-to-paint gfx files that youcan edit in something else for the time being. It'll definitely have scope for bolting on a sprite editor in future, but I think it'd need to be a separate concern from the mapping tool. It wouldn't be hard to write, it's just time! I want something ready asap haha!

[Munchy]

17/03

The ROM tile table stuff is pretty much complete. Now I need to do the other side.  Shouldn't be so tricky with all the code I've already written in place!

here's a demo of stuff so far (if it stops or doesn't play, click it, this seems to be a browser performance-protection thing with big gifs)

[Munchy]

18/03
I've been working on UX and performance stuff. The tool is starting to look a lot more like the "finished" product.  I'm now loading in the gfx file you'll put your tiles on to happily as well (as you can see, I've still gotta actually render it; that's next on the list!) Anyhow, yeah, as I guessed it would, it's coming along nicely thanks to the reuse of other code.

The load times are a little longer than I'd like still (now it's clocking around 5-10 seconds to load all the files and the metadata they need to actually map everything) but the actual run-time performance of the point-and-click aspect of the tool is perfectly fine so that might just be the price the user has to pay.  Sadly, it's the one downside of using a tool like Electron as a wrapper; I can code something very complex very quickly but - even with neat algorithms - your bottleneck is the whole rendering engine and JS conversion etc.  I'm afraid I just don't have the time and energy to commit to learning C++ in enough depth to code a gui right now! 

Anyway:

[mccad]

18/03
I've been working on UX and performance stuff. The tool is starting to look a lot more like the "finished" product.  I'm now loading in the gfx file you'll put your tiles on to happily as well (as you can see, I've still gotta actually render it; that's next on the list!) Anyhow, yeah, as I guessed it would, it's coming along nicely thanks to the reuse of other code.

The load times are a little longer than I'd like still (now it's clocking around 5-10 seconds to load all the files and the metadata they need to actually map everything) but the actual run-time performance of the point-and-click aspect of the tool is perfectly fine so that might just be the price the user has to pay.  Sadly, it's the one downside of using a tool like Electron as a wrapper; I can code something very complex very quickly but - even with neat algorithms - your bottleneck is the whole rendering engine and JS conversion etc.  I'm afraid I just don't have the time and energy to commit to learning C++ in enough depth to code a gui right now! 

Anyway:

Is this tool going to arrange the tiles for you to edit them?

[Munchy]

almost!  Someone (maybe more than one person, probably including me) will - I hope - use it to arrange the tiles in a coherent gfx file.  Under-the-hood, as they're laying the tiles out, the program will map the offsets from the ROM to the offsets in the gfx file. Thus, ultimately, anyone who wants to pixel edit samus will simply need the nicely organised gfx file created by whoever and munchtroid's data map and they're good to go (I'm probably gonna lump the data map onto the end of your gfx file in raw hex tbh; doesn't make much odds to me and saves people having to manage 2 files; the golden rule will be: DON'T COLOR IN THE FUNNY LOOKING TILES AT THE END OF YOUR FILE!!!).  The beauty of doing things this way is the fast turn-around in terms of programming. Writing a fully featured sprite editor with all the bespoke code needed to convert Samus back and forth would take a loooong time (probably half a year or something depending on how much spare time anyone has to sink into a project like that).  Writing a tool like munchtroid is a lot simpler and more-or-less gives us the same result; you'll just have to edit the gfx (when they're ready) in tile layer pro (or something like it).

I hope that makes sense! Between Munchtroid and what I hope will be a bit of community solidarity there will be a pain free way of editing Samus' tiles in the not-too-distant future.  In theory, once the work is done, the mapping part of this program will have done its job and wont really be needed any more.  That said, it's equally useful for other trickier sprite sets (I'm looking at you, Kraid) so who knows what people will use it for beyond Samus.

in theory, it could also make someone else's attempt at writing a full blow SM sprite editor a lot easier too... who knows.

[Sirkura]

Would it be difficult to make the program make a back up of the original unedited rom? There are so many editors out there, and i've seen the horror stories of people accidentally overwriting their original files destroying their hacks. I know its a user error, but it would still be helpful if you were able to edit and test things without having to make a copy of a file every time to open for testing. My thought was have the program clone it internally, then overwrite the original file you open when you hit save.

Another thing i was thinking of, many many many tiles of samus are identical from one to the other. would it be possible to make it only read one of the tiles and automatically change all similar ones? that would mostly be a time save, iirc there are 2000+ tiles in total, and about half of them are duplicates.

[Munchy]

No that wouldn't be too much trouble. The mapping tool doesn't actually do anything other than read the Rom, but it's probably be a good idea if it saved to a bak file too

[Munchy]

I'm looking forward to this tool the possibilities that open up are substantial for customized mods. So far your progress looks quite promising. I'm definitely keeping an eye on this thread. Also I found the editor i was talking about in my last post. it's source code is also available, it may be useful so i'll drop it here

https://jsm.ostehovel.com/

damn! I totally missed this post (I've been working late so I'm usually exhausted when I check this forum!). Yes, that program will  probably be extremely useful! thanks!

[Sirkura]

I'm looking forward to this tool the possibilities that open up are substantial for customized mods. So far your progress looks quite promising. I'm definitely keeping an eye on this thread. Also I found the editor i was talking about in my last post. it's source code is also available, it may be useful so i'll drop it here

https://jsm.ostehovel.com/

damn! I totally missed this post (I've been working late so I'm usually exhausted when I check this forum!). Yes, that program will  probably be extremely useful! thanks!

NP! ^^ i'm glad I could help, even if my coding knowledge is somewhat limited.

[Munchy]

Right, I've hit a bug which probably betrays what I thought I might need to do: re-write my rendering engine.  The good news is, a LOT of my code is very very useful for doing that, the bad news is, it'll take me a while (but as I said before, I like a challenge and I have the time).  I'm also debating changing tactics and actually writing a full Samus Sprite editor.  With that self-same code, it'll be relatively easy to also incorporate enemies and whatever further along.

With what I know now (big BIG thanks to @Crashtour99 for all the PMs about this subject) I feel like munchtroid isn't really gonna be as useful in its current form as I'd hoped because Samus' tiles repeat themselves and it's important that every single tile is exactly where it should be even if it looks like a duplicate.  This would make rendering flat gfx tiles pretty difficult for anyone who doesn' t already understand how she's animated because you'll need to keep cross-referencing your gfx with the raw hex to know which tile to choose.  Screw that!

Watch this space, Munchtroid isn't dead, it's just having a mid-life crisis  :lol:

[Crashtour99]

I should probably clarify that there may in fact be duplicate graphics that can be optimized, but it's more about the animations in such a case.
Like, samus turning right to left, and left to right.  I haven't referenced the actual data, but these 2 transition animations could easily use the same graphics (just play the animation in reverse for one of them), but I'm betting that they don't and they probably even have different tilemaps.
Or:
Samus running right, gun extended
Samus running right, aiming up
Samus running right, aiming down
Samus running right, arms swinging (like she's jogging)
All of these could use the exact same graphics for Samus lower half (for animating her legs).  But again, someone would need to go through and actually see if all 4 of those reference the same data for the lower half, or if it's 4 different copies of the same thing.

I'm positive that there are at least SOME optimizations that can be done.  It's just important to keep the same formatting for how the gfx are laid out, especially for Samus' upper half with the arm cannon and all.

[Munchy]

Ideally, I think the editor would simply load in each tile as if rendering a frame of samus to the screen in-game. If you edit a tile, you'll save directly to the ROM.  Thus you'll be able to see if and where the repetitions are happening because - once they're saved - the editor will load the changes on whichever frame you look at based on the tile offsets.  as for optimisation, I'd like users to edit the vanilla ROM rather than a custom, that saves me specifying that they need to patch their ROMs before using the tool.  Furthermore, since there is repetition, there's more scope for having truly unique outfits.  Yes, it means more editing but also more control.

And here's my private hope all you people out there! In return for building this; when it's ready please would someone be kind enough to release an IPS with samus in zero suit?  Also, appreciating that I can't stop anyone from doing so but: please God no naked Samus; I hate shit like that!    :razz: :razz: :razz:

[Munchy]

24/03

So this is still very much alive and well. I'm reasonably clear on how the tileset is loaded into DMA based on Crash's awesome breakdown of the animation stuff.  I'm still trying to work out how you get from that tileset (which is still kind of higgledypiggledy) to a coherent Samus on the screen.   I'm currently sifting through the github project to try and understand exactly what is pointing where and why in their setup.  It being Java it takes a while to read and understand how all the pieces sit together (mercifully, the guys who wrote it were pretty sensible in their project structure so it's not completely incomprehensible).  I would have liked to do more with it today but I slept like crap last night thanks to some drunken morons in the room above me.

so that's the story today!

[Munchy]

OH. Hang on a minute.  JSM supports tile exports... for literally everything. and will import your stuff back in...

Do we need much more than that?! That's basically what I was gonna write with munchtroid in the first place! Given how complex Samus already is, you kind of need something that just gives you bite-sized chunks of her.  JSM literally already does that.  All you do is export your gfx file and import it again when it's ready.  each one is only the tiles used in that frame of animation. sure, you've gotta put them in order I guess, but it's not like looking at the Tileset in the ROM. 

I'm kind of thinking of maybe writing something much more stripped down perhaps.  I could set munchtroid to translate from each frame into gfx sets for each animation, then have a conversion tool to put it back together again.  Since I'm kind of tempted to draw a zero suit, that'd be useful for me anyway. 

hmmm. I'll mull it over. Kind of subject to time and demand really as I'm probably gonna be a bit busier as of next week.  having something a bit nicer to edit stuff with would be cool, but I don't feel like it adds much to what's already there.  Even with a nicely groomed tileset it's a LOT of work to edit samus...

[Crashtour99]

Except it's not a true editor.  You can't repoint, can't expand animations, can't redefine which animation it goes to after one animation finishes...
It's a VERY basic editor, and can't do all the fine tuned stuff.

[Munchy]

true true.  That goes beyond what I had in mind as well though unfortunately.

[Crashtour99]

That is highly disappointing.   :stern: