[SM] Anyone wanna help me write a user-friendly Samus editing project?

[Munchy]

Hey,

I've read around the subject here and had a play with various hacks that modify Samus' sprite etc.  and - since I'm writing something pretty ambitious - I'm curious to know if anyone has turned the Samus animations into something that can be coherently edited one frame after the next rather than the craaazy nightmare of tiles it's currently setup as?

A lot of what's available seems to be docs, libraries and asm; all of which is fine, but an approach that might be relatively "simple" would be to generate a .gfx template that is completely straight forward to the user from a pixel-art editing point of view and then have a program that points the graphics data from that file to a supplied sfc/smc (given that I'm a webdev with skills in JS etc. I'd probably write something in Electron rather than C++ unless anyone feels the temptation to write it in another language!)

If anyone has a .gfx with samus nicely laid out, that'd save me a huge amount of time.  Better still (though I appreciate I'm pushing my luck on this front) something that tells me what the offset is in the .smc hex for each tile in the .gfx; heck, I reckon I could throw it out in a few weeks if that existed! 

If none of the above, several heads are better than one, so any support greatly appreciated!

[Sirkura]

I'm not sure if there is a reliable table that reorganizes the tiles for use as of yet. There was a java tool that combined tiles for each frame I saw before, but I can't seem to find it now. That is why only a very small handful of hacks have edited anything aside a couple frames I think. With I believe Justin Bailey being the only full sprite replacement. I'm intrigued, you can find all the tile hex offsets for samus's tiles here, they span quite a few banks.

http://patrickjohnston.org/bank/index.html

[Munchy]

thanks,

yeah, PJ's banks are useful to a point, but they're pretty much just a bunch of bytes for that stuff!  I think, if people are interested, I'm going to take a look at breaking down a schema for samus.  As I see it, the first thing to do will be to write something that let's me map offsets of a .GFX file somehow with a JSON object schema.  that way, maybe people can collab with me without requiring a ton of programming knowledge (plus, hey, if anyone who isn't a programmer want's to help, they'll learn one of the most important ways modern devs manage complex data structures with ease!)

non-programmers, think of JSON as a human-friendly way of creating detailed annotated lists.  what I'd like to do first is create the schema, but to do that I'll need to get a feel for exactly what the different animation routines look like.  Then I'll start writing a basic JSON object.  To give you some idea of what a section of it will look like:

Code Select Expand


{
  "morphBall": [{
    "frameNumber": 1,
    "x": 0,
    "y": 3,
    "smcAddress": "$012345",
    "gfxAddress": "$6789A", // people helping wont need to fill this one in, just the address on the SMC
    "notes": "optional information about the tile, should you have something you wanna add"   
  }],
  "runningAnimation": {
    "upperBody": [{
      "frameNumber": 1,
      "x": 0,
      "y": 3,
      "smcAddress": "$012345",
      "gfxAddress": "$6789A", // people helping wont need to fill this one in, just the address on the SMC
      "notes": "optional information about the tile, should you have something you wanna add"   
    }],
    "lowerBody": [{
      "frameNumber": 1,
      "x": 0,
      "y": 3,
      "smcAddress": "$012345",
      "gfxAddress": "$6789A", // people helping wont need to fill this one in, just the address on the SMC
      "notes": "optional information about the tile, should you have something you wanna add"   
    }]
  }
}



[edit] Ah, I finally took a look at the master disassembly too, looks like it could be useful!

[Crashtour99]

Yeah, everything anyone would need for a full and in depth editor for Samus is all in the master disassembly.
I'd do it myself (probably in something like C++ or C#), but I don't know how to read-from/write-to ROM or display the gfx.
I know exactly how it all works though, so if you have any questions on the data or structures, feel free to ask.

[Munchy]

Yeah, everything anyone would need for a full and in depth editor for Samus is all in the master disassembly.
I'd do it myself (probably in something like C++ or C#), but I don't know how to read-from/write-to ROM or display the gfx.
I know exactly how it all works though, so if you have any questions on the data or structures, feel free to ask.

Awesome, thanks. Honestly, I just had a play this morning with manually cross referencing blank gfx with the SMC. Frankly, in the time it'd take to write out the JSON by hand I could actually write about 500 converters in electron with way more efficient data parsing! I've done stream and hex writing for node so it's really not a big deal to do this kind of stuff for me (it just takes time). What I'll probably write is a GUI app that'll let people create a user friendly gfx table AND the JSON map to convert it. In so doing, I more or less have the logic to convert it all back to the SMC afterwards.  Electron is blindingly easy so it'll be an easy project for any proficient developer to hack and upgrade later (it'll be open source of course!). I haven't rendered gfx before but I've completely pulled pdf apart in the past so how hard can it be! I'll post up some questions once I've got the bones of a project together over the week cos some information about formats and stuff will save me a heap of time.

Guys, I have the time, and the stupidly obsessional love of this game to do it! Plus, I haven't written in electron so it'll be good to add that to my professional CV! Fate willing, We're finally gonna have an editable Seamus!

[Munchy]

If I've read this correctly,  https://wiki.superfamicom.org/learning-the-gfx-format-2bpp-game, each line of 8 pixels in a gfx tile in the given mode of super Metroid  (mode 2 mostly if memory serves me) will read 2 Words making each pixel capable of holding 1 of 16 values (the colour metadata that is used in conjunction with tlp palette files) Is that correct?

So each offset I see in tlp is just a pointer to a set of 8 X 4 bytes somewhere in the ROM?

If all the above is true, writing a conversion GUI shouldn't be too much trouble!

[Munchy]

Yeah, everything anyone would need for a full and in depth editor for Samus is all in the master disassembly.
I'd do it myself (probably in something like C++ or C#), but I don't know how to read-from/write-to ROM or display the gfx.
I know exactly how it all works though, so if you have any questions on the data or structures, feel free to ask.

On the subject of how to read from and write to, it's just a file full of hex as far as your pc is concerned. All you need is the offsets (to the best of my knowledge, the pc addresses) and you're basically there.  A file stream writer doesn't care what it writes to, it's just bytes as far as it's concerned.

[Munchy]

Progress report 11/03

the table format is setup, I also have the basic stream reader setup. I'll start fiddling with the hex this evening and see if I can find the right bytes

[Munchy]

Yeah, everything anyone would need for a full and in depth editor for Samus is all in the master disassembly.
I'd do it myself (probably in something like C++ or C#), but I don't know how to read-from/write-to ROM or display the gfx.
I know exactly how it all works though, so if you have any questions on the data or structures, feel free to ask.

On the subject of how to read from and write to, it's just a file full of hex as far as your pc is concerned. All you need is the offsets (to the best of my knowledge, the pc addresses) and you're basically there.  A file stream writer doesn't care what it writes to, it's just bytes as far as it's concerned.

Yeah, just to confirm, I've read 100 bytes of an SMC and cross referenced with a hex editor. P address is the same as the hex output from my byte stream. No problems!

[Munchy]

Yeah, everything anyone would need for a full and in depth editor for Samus is all in the master disassembly.
I'd do it myself (probably in something like C++ or C#), but I don't know how to read-from/write-to ROM or display the gfx.
I know exactly how it all works though, so if you have any questions on the data or structures, feel free to ask.

hey man, I think that transition table will be useful for animations, if - for example - someone wanted to stick all the pieces together and animate them in a future version of munchtroid or - indeed - to add custom animations to the game. 

The clincher for actually translating the gfx is the tileset which you can find the offset of using TLP: $DEA00

As I predicted from my earlier post, each tile is 8x4 bytes, 

so here is the first tile, samus' leg... the raw data

3A 3E 15 1F 11 1F 10 1E 10 1E 0A 0E 0A 0E 0A 0A
00 1E 00 1F 00 1B 00 1A 00 1A 00 0A 00 0E 04 0E

Each row of a tile is broken up across 16s as below:

READS FROM HERE -> 3A 3E | 15 1F | 11 1F | 10 1E | 10 1E | 0A 0E | 0A 0E | 0A 0A
THEN FROM HERE --> 00 1E | 00 1F | 00 1B | 00 1A | 00 1A | 00 0A | 00 0E | 04 0E

003BBAB0 <== first row of pixels for samus leg stood facing screen is the result when you break read the bits below from     
                      bottom to top.
00111010 = 3A
00111110 = 3E
00000000 = 00
00011110 = 1E

and, I've physically cross referenced that with TLP and it's precisely the correct data, so I'm in business!