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

[Munchy]

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).

Hmmm, that'd be an interesting one. If you added them to the file in libs, then in theory they should just work! I haven't checked what's actually in a build yet, it'll be interesting to see how you get on! There's always room to make custom stuff possible. Adding poses would be pretty easy in theory!

[Munchy]

darn, it's compiled the json file I was hoping you'd be able to edit :/ that said, if you've overwritten one of the duff poses in the game with new animation and it still points to the same chunk of VRAM, it should just work.

I might investigate how I can expose some config files at some stage.  I'm already drafting a "beta" to-fix list!!

e.g.
- I think the Menu is missing samus' dying poses
- I need to find the palette for hyper beam
- I need to find the speed boost palette

[Munchy]

Manual Now available :)

Manual

[Munchy]

SUPER MUNCHTROID v2.1.0



a comprehensive editor for Samus. 

REQUIRES UNHEADERED SMC! WILL NOT WORK WITH PAL!

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

downloads:
win: Super Munchtroid-win32-x64 2.1.0
linux: Super Munchtroid-linux-x64 2.1.0   

[EDIT] Sorry the links were the wrong way round! I suck :P If it doesn't have an exe, you're looking at the Linux version!

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

documentation:
Manual

[Munchy]

SORRY! The download links were the wrong way round. I swear I checked em like 20 times yesterday  :lol: fail!

[Munchy]

Video Tutorial

[Munchy]

Ok version 2.2.0 now out. You only need to download this version if you wanna repoint stuff like the DMA cos it exposes all the ROM statics from my files. 

I've just found all the different palettes I was missing.  I need to do some maths to work out the pointers but i'll get it done at some point in the not-too-distant future. Also, the palette drop down uses a JSON file containing data I more or less lifted straight out of JSM.  Honestly, it needs refactoring because it's a nuisance to edit at the moment.  But i'll need to change my code a little to get it working right.  so 2.3.0 - when it's ready - will have all the palettes I can find for samus available in one hearty lump.  Honestly, then I'm done done done! I have spent waaaay too much time on this code and I'm sick of the sight of it  :lol:

[Munchy]

FOR REAL

I decided to just get the palette stuff over and done with... Version 2.3.0 is up! Now FOR REAL, I am downing my tools before I go any more insane  :lol: :lol:

SUPER MUNCHTROID v2.3.0



a comprehensive editor for Samus

----------------------------------------------------
NOW FEATURING A TON OF SAMUS PALETTES!
----------------------------------------------------

REQUIRES UNHEADERED SMC! WILL NOT WORK WITH PAL!

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

downloads:
win: Super Munchtroid-win32-x64 2.3.0
linux: Super Munchtroid-linux-x64 2.3.0   

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

documentation:
Manual

Tutorial:
Video Tutorial

[Munchy]

Hey @Crashtour99 come across a weird bug! @Oi27 discovered it by flipping samus on her head (but in fact, it turns up whatever the layout).  There's a secret 8x8 pixel sprite in her lift pose!  have you seen this at all in your animation tinkering?

I've checked with another pose, it does seem to be something specific to that pose... weird.

[Crashtour99]

I haven't but it doesn't surprise me.  Should probably be careful, as it may be sharing the tilemap with another animation.  Or it could just be silly stuff left in from when they were developing/drawing stuff out.  It's hard telling.

[Smiley]

The elevator pose does have one extra tile drawn from common sprites (not included with any other Samus graphics). It's for hiding the light on one half of the chest.

[Munchy]

The elevator pose does have one extra tile drawn from common sprites (not included with any other Samus graphics). It's for hiding the light on one half of the chest.

AHHHHH! Yeah I just discovered it too! It's actually redundant. The VRAM has an unhilighted chest piece that draws over the top of the common sprite tile anyway.  Here's the proof!  :yay:



so... for now the solution is to load your ROM in TLP and navigate to offset D5600.  the 2nd tile to the left is a chest piece. Simply replace it with a blank tile. bish bosh. Probably what I'm gonna do is have SMunch wipe this tile for you whenever you save the lift pose (I can't be naffed to write environment checks to see if you're gonna be using more than one ROM and it isn't expensive to overwrite 32bytes).

[Munchy]

2.3.2 out :) what the hell, it didn't take much to fix!

[Munchy]

BAH, beg your pardon @SMILEuser96 you're completely right... when you're in-game, it uses pose 0; even when you're actually saving your game... But when you reload from save it defers to common sprite 1 and uses different tilemaps!!! WHAT THE HELLLLLL :P

ugh. I think there's tilemaps missing from my collection. What a nuisance. I'm gonna have to look through the bank and see if I can spot some addresses. cos that "samus loading from save" pose is definitely not derived from the same place as pose 0 :/ probably I'm gonna need to make some kind of "special poses" menu (I still need to figure out the "Samus dying" tilemap and I suspect it's also got weird logic.

[Crashtour99]

Yeah, there's definitely a few weird ones in there.  Like for the loading animation, I never found where the call was for it, but the tilemaps and animation pointers are there in a big block near the beginning of the bank (you can see it easily enough in the animation disassembly).  The elevator pose uses the first frame of it I think, but then something tells it to move past that first frame and it goes on to do the lightning effects.  Sort of like how the "ready to walljump" "pose" is just a specific frame of the spinjump animation, and the physics routine holds it on that certain frame until you either jump, or the conditions are no longer met (holding away from the wall while within a certain distance of it).  I haven't looked into how the crystal flash or death animations work, but I can only assume they have similar oddities in how they operate.  X-ray is probably another one, since her helmet will actually angle up or down depending on the angle of the x-ray beam, so there's likely some routine doing some minute controls over the animations manually for that.

[Munchy]

I'm really not convinced that the death sprites necessarily have a tilemap. Nothing in the HexD/PJ is giving me any evidence to the contrary and the actual graphics in ROM (almost drawn entirely as they appear on the screen) ... I dunno. It's possible they didn't bother; I guess because when samus dies there's no movement just a static location on screen.

On the bright side, I think I've found the "load samus from save" VRAM load... I'm gonna do some homework...

[Munchy]

ok... after a few hours of investigation, here's some theory.  there are a bunch of tilemaps I can see in PJ's map that occur before the earliest tilemap used by Samus in our conventional list of poses... I'm also pretty sure that bottom DMA index 08 actually has references to Samus' load routines... so I'm gonna write something that matches up the low tilemaps from before the first conventional pose with the tiles in that DMA.  If one of the sets of tilemaps starts to line up (and changing their metadata is reflected in the game) then I've found what we need to edit the load frames. 

If none of those pay off then the pose is hard coded (I can't see any other option)... in which case I'll make the tiles available (I'll do the same with the death pose) but you won't be able to move em about you'll just have to edit everything as it is (the tilemaps are what allow for all the nice drag and drop and hflip stuff SMunch supports elsewhere).

[Crashtour99]

Just thought I'd point out real quick that Munchtroid doesn't actually display the walljump frame in the spinjump animation.  Like, the actual frame of animation that the jumping routine locks onto when you press away from a wall during a spinjump.  It should be there in all three spinjump types (regular, spacejump, and screwattack) at the end of the animation cycle (they all point to the same tilemap & gfx though). 

[Munchy]

Just thought I'd point out real quick that Munchtroid doesn't actually display the walljump frame in the spinjump animation.  Like, the actual frame of animation that the jumping routine locks onto when you press away from a wall during a spinjump.  It should be there in all three spinjump types (regular, spacejump, and screwattack) at the end of the animation cycle (they all point to the same tilemap & gfx though).

interesting! Yeah, I was wondering about where the walljumps had gotten to. I'll probably make them their own poses, thinking about it (maybe in the special poses tab, since they kind of break the rules!)

Please can you chuck me it as an issue on github?  :^_^:
---------------------------------------------------------------------------------
10/05

I'm recording the following for posterity more than anything (I need to write it down somewhere so I can remember where the hell i got to). This is deep deep territory. Even PJ's doesn't really know much about this stuff.

so, ok. I'm working on a botched Smunchtroid at the moment that'll probably be shelved once it's done its job... and lo, I have definitely found the DMA references to Samus' pose (lightning and all) when she loads from save.  And I'm currently going through the painful process of reading that manually rather than using things like the frame references to work out how they fit together.  The good news is that both DMA tables are short and fairly obvious to get your head around:

It looks like DMA reg F0D5 index 0 & 1 are dedicated to the poses of Samus facing forward while loading (power or var/grav suit respectively) The other chunks do not look like they'll have any bearing on proceedings.  One very VERY strange thing is, I was expecting Space in VRAM to be the reason why the devs used a common sprite to overlap her chest piece.  BUT THERE'S A SPACE FREE IN THE VRAM DATA!!! And they've only included the one half of her chest piece. Go fig.

So, if my future tests pay off, it'll be completely safe to delete that stupid tile from the "common sprites"  :stern: :stern: :pwuh: :pwuh: there's literally a big juicy 8x8-pixel-sized piece of memory sat there doing nothing.

I've also figure out why all my attempts to find the tilemaps by searching for the raw sprite data based on the existing poses has failed: the order of the DMA is totally different :/

So the top half of the VRAM uses DMA E8D0 and my research has discovered that this whole table is excluively devoted to the 9 possible lightning tile loads. 

So, I can watch the game animate these in geiger to get a sense of how many frames it's gonna need (it's quite a few I think, I always thought that was one of the coolest animations in the game).  Then it's into the arduous work to try and find the tilemaps.  They probably live somewhere around the 0x9117A mark.  It'll really just be a case of loading ALL those tilemaps up to conventional pose zero and seeing if any of them make any kind of sense (I'm fairly sure it'll be in there somewhere). 

as for the death pose, still nothing :/ really not sure if any kind of tilemap metadata exists for that one.

[Metaquarius]

There is no death "pose" so to speak. This is just a bunch of spritemaps (9 for each side), pointers are located at $92:90C5, graphics are at $9B:8000

[Munchy]

There is no death "pose" so to speak. This is just a bunch of spritemaps (9 for each side), pointers are located at $92:90C5, graphics are at $9B:8000

Thanks, Good to know. I'll probably write something different for handling the death sequence in that case... that or defer to TLP (if it ain't broke, don't fix it!)

[Munchy]

Hmmm. Jury's out on the load tilemaps. So here's my method:

I load the VRAM with the data from the aforementioned DMA tables, then I take sprites from the default pose in SMunch and line them up with how I would expect them to look in the load pose. as I'm saving, I run a trace to spit out the buffer data for each one of the sprites.  Then I take a couple words and search for them in the ROM's hex. If I find something, I cross ref adjacent bytes with the other buffers I've saved.

In this fashion I have actually found 1 promising patch in the data, but it's buried away elsewhere in the ROM.  That doesn't mean that it isn't the right data (I've made very broad assumptions about what the sprites might look like and how they're positioned so there's a strong likelihood it'll be setup kinda differently).  The next step will be to try and load this data as tilemaps and see if I can get a coherent Samus.  If that yields something useful, great! if not: that proves - within an acceptable level of experimentation IMO - that tilemap data simply doesn't exist for when samus is loaded from a save.  In which case, like the death pose, you'll have to pixel shift her manually if/when I add the frames to the editor.

so that's where it's at right now.

[Crashtour99]

I just thought of something...
The arm cannon opening/closing animations are done by a routine that directly edits OAM, so it modifies the tilemap data that's already stored.
I certainly hope the loading animation doesn't do some silly stuff like that...

[Munchy]

I just thought of something...
The arm cannon opening/closing animations are done by a routine that directly edits OAM, so it modifies the tilemap data that's already stored.
I certainly hope the loading animation doesn't do some silly stuff like that...

At this stage, I wouldn't be surprised in all honesty.  I've been scouring over this stuff for hours.  The "tilemaps" that PJ's mentions (before the conventional tilemaps) are busted. I'm not seeing any rhyme or reason to any of them quite honestly. There's a LOT of unused crap when it comes to Samus. All of which probably tells us that the devs must have had a hell of a time coding her. It makes sense; I sense that metroid was hella complicated compared to a lot of other games from that era of the platform (maybe not the later games). Samus: a highly flexible character with - as far as the vanilla game is concerned - pointless degrees of modularity (I mean, it's great for us lot that you can collect and use nearly anything in any order but when in the hell would you actually need some of the variations you can achieve in terms of equipment as a nooby player!)

[Munchy]

EUREKA  :grin: :grin: :grin:

Guess what I just found!! All of samus' loading tilemaps and VRAM nicely organised - I kid you not - right under my nose the whole time!!

I ended up checking near the start of the DMA request stuff (what PJ calls "Samus tiles animation - animation definitions") for index 08 of either the top or bottom DMA table.  I jumped to pose 0 (facing forwards, power armour) and thought: hang on, why is there this huge collection of bytes when I know that pose 0 only has 1 frame of animation? then I saw index number 08 neatly stretching on for index after index and my brain exploded.  The problem isn't the tilemaps or the DMA. It's the table that tells the SNES how many frames to animate for each pose (and how fast to animate each of them).  I call this table the "FRAME_DELAY_TABLE", I use it to tell SMunch how many frames of VRAM and sprites are gonna load for a single pose.  It's literally never failed me (or so I thought!)  The frame delay table only records 1 frame for facing forwards. So what's really going on here is a whole other pose buried just behind the lift pose whose frame rate must be managed by some other process.  So it'll be a piece of cake to load; I just need to create a "special poses" tab and have the drop down run a bit of custom code.  Voila!

GUYS I CHUFFING FOUND IT! WOOOOO!  :heheh: :heheh: :heheh:

[edit] OH MY GOD, I just counted what's there... THERE'S 94 frames of animation for EACH pose type (ie. power and varia/grav)