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

[Crashtour99]

Samus will take time to edit and editing her will require some trial and error as sometimes your change to one tile in one piece of VRAM will actually edit said VRAM in a bunch of different places.   Then there's the issue of which poses are actually used by the game and which are who-knows-what.

Ahhhhh...  So there are shared tiles then.  I was wondering if that was the case or not.  Does add more complexity to the editing side of it.
A method I just thought of for which poses are used or not.  One could always cross reference between a vanilla ROM and Auximine's Justin Bailey patch.  He made that the hard way without an editor, mapping things out in the ROM graphically, so if you go in and look, every gfx tile that isn't used is labeled in hex.
It should be possible to find the locations of those tiles, and cross reference them with the DMA table entries in the animation disassembly to figure out which DMAs point to the unused gfx, and from there backtrack through the animation data to see which pose they were supposed to animate with (assuming they were pointed to / indexed correctly of course).

Fascinating stuff though Munchy.  I'm really curious about pose $45 now.  haha  It should be really interesting to dive into it and see all the odd unused stuff and just how broken it all is.   :lol:

[Munchy]

Ah, I made the assumption that they were shared references based on your document! I may be wrong about that then!  :lol: it'll be easy to check. My program won't be interested in what you're saving where. You'll save directly to the raw tileset. so once you write to the ROM, if a bunch of different VRAM tiles point to the same tile in the raw tileset, they'll all be changed. I wouldn't be surprised if some of the duff grapple routines shared VRAM. I'll be able to test all this as soon as I have a crude version of the editor up and running! It'll be a little frustrating for users at first but if there's a lot of repetition it'll ultimately save them some time I suspect.

[Munchy]

18/04

I'm on Zebes. The internet is terrible so I won't be posting much for a few days. Suffice to say, work ongoing nicely. I'm venturing into stuff JSM never did. Stuff around sprite indexes and whatnot. Basically, I want users to be able to choose their VRAM offset. JSM had made a start on this but the result is very glitchy. Shouldn't be tricky in SMunch. I've also wired up being able to move the sprites around and done some colour work so you'll know what you're actually moving. I'm having to wait a bit on the editor window unfortunately cos I'll need internet to read up on some canvas tools to get it how I want it. Plenty that needs doing in the meantime however.

[Munchy]

19/04

I have no idea how but I found a spot with phone data, (no joke, I'm on a tiny island in the middle of the Caribbean right now!) Anyhow, today I wrote in the ability to drag an active sprite around the canvas.

I'm debating whether to split the canvas up into multiple canvases right now. The canvas that renders sprites and VRAM is a very big and complicated concern. Really, the fewer canvases you have the better because they're relatively expensive to render. The downside to writing everything in one canvas is that it means you have to write ALL of the user interface for all your components from scratch. And that gets bulky and mathematically fiddly very quickly! Canvas is nothing more than a square you can draw pixels to. No nice html tags or handy vuejs wizardry, just pixels. Great for rendering a SNES Rom, terrible for writing UIs!

Anyhow, gonna mull over how best to organise stuff, I'm not wholly happy with the layout at the moment. I'll figure it out.

[Crashtour99]

Would having 3 canvases make rendering to intensive?  I think that's the most you'd need if you split it up.
1 for the VRAM display
1 for displayed/assembled sprite in which the locations can be adjusted/edited
1 for gfx editing (select a tile in the VRAM display and it appears on this canvas as a single 8x8 tile for editing (or maybe a 16/16, dunno how feasible that would be))


I like the layout of the VRAM display and assembled sprite, so maybe having the gfx editor to the right of the sprite display, still under VRAM.  Gives it a nice tight appearance.
Maybe have the palette displayed across the bottom, so when editing the gfx you click on a palette color to select it.
Just spitballing ideas here since I have no idea how your program works under the hood, so to speak.  lol

[Munchy]

22/04

I went with 3 canvases :) seems to perform just fine and means I can use JS and HTML to show hide stuff!

Here's the work so far! I've also done a fair bit of tidying up on the back end.

My next job is to do the in-memory editor and the left/right click on palette colours (by default, html buttons only listen to left click, sure it's easy enough to work around that).  I'm looking forward to this as this'll genuinely be the bit where users can edit the tiles!

Folks I know it looks nearly done (it's definitely well over half way), but it's still got a while to go. I want to include undo/redo routines in the editor; these can be notoriously fiddly to write (and i've seen many many UIs mess it up) and a bunch of editor tools like copy/paste. hopefully a few weeks and I can start looking at compiling builds for people to test.
But really, the last big leg of the project is writing the save routines (probably about as hard - if not harder than - the load routines).  I have to convert everything back to bit masks and hex.  Hopefully it wont take too much time but I'll probably go to the trouble of writing unit tests for them (I haven't bothered thus far because - hey - smunch is a pet project and unit testing is soooo booooring) because I want to make sure absolutely everything goes back in the same places as it came from. I'd hate for you guys to do an hour of careful tile work and lose it all because I corrupted your ROM with 1 misplaced number.

anyway, I'll stop writing Lord of The Rings, here's a screen shot!

[Munchy]

23/04

BIG MILESTONE YOU GUYSSSS!!!!

The miracles of modern development: reactive variables are paying big dividends now. This editor was incredibly easy to throw together... and - pretty much - it's all just pointers under the hood so the redraw rate is nice and fast too; there's very little active object creation going on.  I have a few bugs to fix but it's pretty much there.  Kind of clever really. you hold left/right mouse down while on the canvas and it arms a reactive variable that tells the software you're gonna draw something (and in turn, updates the in-memory vram for the current pixel).  then every time you move the mouse across a different pixel, if the reactive variable is still enabled (ie. you haven't lifted your finger off the mouse buttons) it'll repaint that pixel in the in-memory VRAM.  Thus: an editor!

so the todo list for front-end stuff now is:

- fix some small bugs in the editor
- make the editor update the right pixel when you've called h-flip and/or v-flip (just a bit of array gymnastics, no biggy).  using h-flip/v-flip on an editor will NEVER flip the tile in the VRAM. I want the principle of h-flip/v-flip to behave as it does in the sprite rendering.  Thus, it's only there as an aide to help you design (because Samus might be using a particular v-ram tile upside down and back-to-front.) You'll be thanking me when you see the tiles for her screw attack :P
- implement undo cache and - depending on how much patience I have - maybe a redo cache as well. 
- add proper palette changing stuff in. I want you to be able to set palette colors in Smunch as you can in TPL and SMILE.  Not too hard to do!

I've debated writing stuff like a fill tool, but I might save that for later since it isn't really critical.

the back end stuff will be ... how the hell do I make all this stuff go back in to hex! It'll be a good challenge (I'm really looking forward to it actually), but we'll cross that bridge once all the in-memory stuff is as tight and stable as I can get it!

[Munchy]

24/03

Editor h-flip and v-flip buttons are now working correctly, which is awesome.

One of the things I'm currently mulling over is how the drawing functionality would work best.

Right now, everything hinges on users depressing left or right mouse click *inside* the editor canvas.  This has some limitations.  If the user's mouse cursor leaves the canvas, the canvas will have no idea if/when you have let go of the depressed mouse button.  This leads to the drawing function continuing when you re-enter the canvas - irrespective of whether you're actually holding the mouse button down or not.  This issue actually appears as a bug in TLP at the moment when you hold down the right-mouse-button.

so there are 2 options as I see it.

1. once the user leaves the canvas, switch off the drawing variable.  However, that way, even if you continued holding the mouse and slipped off the canvas by just a pixel - tough luck!  This is my current solution, I'm going to investigate whether creating some invisible padding around the canvas will allow me to give the user a bit of grace around the edges of the canvas.

2. the more fiddly option, set up an event listener that listens for click and hold *anywhere* in the window, but only arms the drawing variable in the first place when a flag tells it that you're inside the canvas.  The disadvantage with this approach is code readability (which, as the programmers among you will testify, is not a good thing if you're trying to make something other people can contribute to); there'll be a seemingly irrelevant event listener sat at the top of the HTML hierarchy and yet more variables needed in the store so that the event listener can instruct the editor...

dunno, there's no "right" answer really. it's just one of those things.

[EDIT]

went with option 2. It just feels more intuitive.  One little bug I had to fix was adding a handler for if your mouse went outside of the program (in fact, i address this by having an event listen to when your mouse re-enters the program area).  Hey, If you're so sloppy with your drawing that it falls out of the application window, sorry, I'mma cancel your mouse click :lol:

[Munchy]

I wasn't sure people would get the h-ref/v-ref editor modes so here's a visual demo showing what I mean, If you watch the VRAM tiles and the sprite, you'll see that both are still being edited the correct way round even though I'm editing the tile back-to-front and upside-down.  As I say, the aim is to make the editor helpful when you wanna cross-reference what you're doing with how it looks in the sprite window.  This is especially important for the super complex poses like screw attack (I don't envy anyone trying to re-draw screw attack!) 

[Munchy]

copy/paste nailed. works across any pose and any frame.  here, have a 3-headed samus.



also re-designed the VRAM hilighter boxes to be brightly coloured outlines.

soooo onto the potentially fiddly joy of undo/redo :P

[Quietus]

Quick - somebody create Metroid: Hydra. :grin:

[Munchy]

25/04

Now you mention it @Quietus I was thinking it'd be fairly easy to make 3 headed samus metroid (I'm looking at you, competition hackers!)

So progress: undo/redo for a single tile done. I considered making it undo/redo across multiple tiles but - quite honestly - that brings history issues with it that make the algorithm more complicated (I tried using what I'd already written and I was getting some weird behaviour, tells me that I'd probably need to write a more complex log history to do comprehensive undo/redo so I'll shelve it for the time being). 
For now, you'll get an ongoing history of 16 undos/redos for the given tile you're editing. If you switch tile, it'll wipe your undo history. It's already way more reliable than the undo/redo in TLP so it's a net gain.  I might add a few bells & whistles elsewhere to help (e.g. I've decided I wanna throw in a "default" button for sprites, so if you move one around too much and forget how it goes back you'll be able to hit "default" and it'll jump back to how it was in the latest save).

Here's a demo.  I switch on the editor's grid-mode too, just to show you what it looks like (I figure some folks might want that when they're working on a blank tile.)

[Munchy]

26/04

ooooooooooookay.

so I think I can sign off on the front end in-memory stuff as finished  :bounce: :bounce: :bounce:

Quick run down of new features I show off in this demo:
- You can undo a palette color to how it's saved in the ROM.
- You can undo a sprite drag to how it's was when you activated it.
- when you're in "Sprite mode" (ie. able to drag sprites around), you can now use right-click on the VRAM to select a tile to edit.  I thought this'd be useful because it'll help you to know exactly which tile you wanna work on based on where it's being visibly rendered to the screen (rather than having to fish around duplicate tiles)



so I'm onto the last leg now: saving Samus' data back to your ROM!  Hopefully I can reverse engineer what I've already written to some extent.  at the same time, I need to put a bunch of flags in to the program to stop you accidentally performing actions that might result in your losing data.  (e.g. if you wanna keep your data, you will HAVE to save tile and sprite changes before jumping to a different pose, no way around that I'm afraid; the system runs as fast as it does by only loading the chunks of data it needs to draw the three canvases and save them. When you "load" a new ROM, it's actually a bit of a white lie, you're just loading the first palette, the first pose and some metadata so the programme knows where it has to look to load other poses/palettes)  Similarly, if you wanna keep your palettes you'll HAVE to save 'em before choosing a new palette from the drop down list.

oooh, and I need to work out why a handful of poses are erroring still :/

anyhow, I took a flight at 4am this morning and couldn't sleep so I'm running on fumes here. toodloo!

[nodever2]

Wow man, this is looking super promising! I love all the progress you are making and can't wait to see the finished product :grin:

It is really awesome to see how many features this editor has. I think this tool will make Samus editing much easier, and it also makes me excited to see what you create in the future :)

[Munchy]

thanks @nodever2 I really wanna get back to my big hack when I'm done  :grin: I miss all the tile design side of things (and the odd bit of fiddly ASM as it goes)

27/04
Tilemap issues fixed! I'm sort of amazed Smunch even worked with the bug I found in my tilemap pointer logic! One big gain is that this should reduce load times significantly on larger poses (I was loading incrementally larger buffers for something that only ever needed 2 bytes, derp). Anyhow, bug squashed and all poses now load without errors which is super satisfying. In fixing that, I've been able to look at some of Samus' super obscure poses.  check this out! This is the pose for when Samus gets drained by Mother Brain or Big Metroid.  Notice that, when you strip off her arm cannon, there's an arm underneath!  She shares this set of tiles facing left and right so I'm guessing it meant they could switch her either way and draw the gun in over the correct arm.



without the arm cannon, she looks a bit like I do when I'm trying to solve a bug :lol:

[Munchy]

I'm also debating making the source open soon.  Unfortunately, for "reasons", I will have to wipe the commit history.  But you'll get the latest snap shot for forking and whatnot.

[Munchy]

28/04

Greetings from Quito, Ecuador :)

I'm tackling the boring logical stuff around saving at the moment.  In other words: warning you if you're gonna kill your changes by accident and making sure I can get away with saving as little as possible.  Why do I wanna save as little as possible? Because, even though writing to files is pretty safe these days (good riddance, floppies), consider:

1. The user's machine could power-off at any second: nature is still a thing (between you and me: people forget this waaay too easily nowadays. computers are very refined lightning boxes; and we're only ok at controlling that lightning. If you gamble with billions of miniscule processes a second: physics will always eventually beat you.  Be that with a power cut or some astronomically difficult to predict set of environmental/contextual variables.  Ever had an OS boot up and behave like trash for no obvious reason only to behave fine when you restart it? that.)

2. The less Smunch saves, the less energy and time your processor spends worrying about it.  Ergo, better performance.

3. The less Smunch saves, the less of your ROM is exposed to some hitherto unknown bug.  Obviously I'm aiming for a build that's bug free, but I am only one human bean.

so yeah. I'm gonna work on saving palettes tomorrow evening probably (since that's the easiest of the 3), then sprites and then DUN DUN DAAAH: VRAM (ooph, engineering that is gonna be a good brain workout!).

[Munchy]

29/04

having chewed my way through several test ROM files thanks to the Node FS' helpfully unhelpful "write" mode command :lol:, Smunch is now playing nice and saving palettes (because pffft, what loser would expect "write" to - y'know - simply write to the file rather than zeroing and truncating everything but what you're writing to the file  :pwuh:)

aaanyway, you live and learn; and I know for the future! 

thus!



1 save mode down! 2 to go!

[Munchy]

30/04

I've written the Sprite Save logic and it appears to be behaving correctly. I have made the brave choice to ignore some of the seemingly redundant metadata in Samus' tilemaps (because it would require making calculations that are basically unnecessary; The stuff I save back is appearing in the game quite happily in spite of this.  As I've discussed elsewhere, there does seem to be some bits and pieces in there that were simply never used.  go fig.

anyway, Smunch can now save an individual sprite, and each sprite now has a little save button; but this will get unhelpful fast, so my next job is to write a save button that will let you save all the changes to an entire tile map.  Depending on energy levels tonight, i'll try and get that done asap.

And, no, I've decided not to write unit/integration tests. No one is gonna pay me for the 16 hours or so I'd need to cover this stuff so ... meh.  But I'm doing everything - functionally speaking - to make sure it works as desired and, thus far, everything is behaving itself pretty well.

Fast progress.  Heck, I might even have a beta in a week or so.

[Munchy]

30/04 cont'd

you can now save all edited sprites in a pose at once with a single button.

I've also been doing a bit of housekeeping to make the code clearer for future developers.

- I need to fix a small bug in undo/redo related to h-flip/v-flip (doesn't seem to affect stability, but generates an exception so i want it gone)

SHORT MESSAGE: 2 of 3 saves down YOU GUYSSSS!!!! 1 TO GO!

[Munchy]

01/05

So,
- fixed the undo/redo issue. nothing serious.
- did a bunch of admin to make sure I only retrieve the tiles marked as updated
- ummmm, I need to sit and run it through on main, but I kind of nailed the whole of the conversion algorithm for saving VRAM tiles tonight :whoa: what can I say, I love functional programming and doing complex array math is so easy to do with functional programming!

so, yes. that's massive.  Really massive. But I'll have to see if it runs as smoothly as I think it should tomorrow when I'm less tired!  And of course I still need to actually wire it all up... The point is, if the converted outputs match the hex dump from the ROM tomorrow, that's ALL OF THE MATH DONE!!!

Oh, another thing, I think I mentioned that sometimes Samus' bottom sprites use her top VRAM.  It didn't appear that the game ever did the reverse and had her top sprites use her bottom VRAM but I figured it'd probably work since the game was (probably) only interested in indexes and didn't have any special checks in place.  I tested that today, and sure enough, you can mix top and bottom interchangably.  This makes the whole VRAM/Tilemap stuff a lot more flexible than I had originally thought!  To celebrate, here is a demo of "Samus Monster Legs", a hideous creature using bottom VRAM in top Sprites!

[Munchy]

02/05

you can now save the currently edited tile from VRAM! :) 

I have to do the "save all tiles" stuff finally, then I need to investigate how to actually build this project for all you kids and those there new fangled "Windows" operating systems I've been hearing so much about :P

oh, and here's the repo.  If you know how to use NPM and have Node installed, you can actually give this a go!
[edit] https://github.com/munchyMouth/super-munchtroid

as I say, a proper release to follow very very soon!

OMG, I wrote this in just over a month :lol:

[Munchy]

Just pushing the changes up now.  so yep. Munchtroid 2.0 ("beta" I guess, although I can't think of anything that needs doing other than if someone wants to write a bunch of unit/integration tests.)

SO now I just gotta write instructions and build this son of a gun.

[EDIT] gitlab, unfortunately, is being a nuisance so I've moved this over to github :/
https://github.com/munchyMouth/super-munchtroid

[Munchy]

SUPER MUNCHTROID v2.0.0


a comprehensive editor for Samus

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

downloads:
win: https://drive.google.com/open?id=1XxUIC8Hp8AWWD8gAE-_TDBRP9CqYWPJf
linux: https://drive.google.com/open?id=1bnr-vUzHM_DIHgCyBXta8u5gPqyJ-FcH

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

documentation:
coming soon.

to check when downloads will be available, please refer to the Opening Post of this thread (ie. I wont be updating this post here!!!)

[Crashtour99]

Wooo!  Great job Munchy.  I'll have to take a look and see what it's like (especially if it'll handle/recognize my push-block animations and transitions).