Making a level editor would be awesome but I now see that without deconstructing the logic of the header information in the game it would be impossible to modify a stage size or amount of objects it can hold.
By the way, is it hard or even meaningful to map out a ROM? As in, "$60F58 here is the something that does this". Are there any tools for such a thing? I ask because I wish to make a cleaner document about what we already have. 
Actually SFXEdit already have the level editor, except it is done in hexa decimal edition form but you can actually already edit / modify Starfox level through the application
Map out the rom is a nice idea, it is the easiest way then to read / decode and understand the rom for someone else it but that would require much much time to do it ! Right now we already have many informations but you are right, they need to be compiled and set in a good form so we can easily read them. And as far i know there is no ready to go solution for that... except taking notepad and writing all by hands :p
By the way, here is the format of the object header as i now understand it :
$00: vertex address offset (2 bytes, low byte first)
$02: bank number (1 byte)
$03: face address offset (2 bytes, low byte first)
$05: Z position ?? (2 bytes, low byte first)
$07: scale, used as left shift operator: value <<= scale (1 byte)
$08: unknown address, collision infos ?? (2 bytes, low byte first)
$0A: size X (2 bytes, low byte first)
$0C: size Y (2 bytes, low byte first)
$0E: size Z (2 bytes, low byte first)
$10: Z distance / alignment ? (2 bytes, low byte first)
$12: palette address (2 bytes, low byte first)
$14: id1
$16: id2
$18: id3
$1A: id4
Bank number = 0 is a special value meaning there is no vertex nor face data attached to this object.
To compute final vertex and face data address in the rom we have to use this formula :
((bank number - 1) * $8000) + address offset (add $200 for headered rom)
Example of low poly arwing model header :
vertex address = ($10 * $8000) + $F173 = $8F173 ($8F373 on headered rom)
face address = (($10 * $8000) + $F196 = $8F196 ($8F396 on headered rom)
There are many informations I'm not sure about :
$05: Z distance ?? (2 bytes, low byte first)
$08: unknown address, collision infos ?? (2 bytes, low byte first)
$10: Z position / alignment ? (2 bytes, low byte first)
$05 seems to be something as Z distance of object but i'm really not sure, the filed is rarely set which make it even more difficult to figure.
$08 field is rarely set too but when it is done, it seems to be a 16 bit address... Note that field is almost time use of Arwing object or some big boss / base object.
$10 is almost time very close to the value set in $0E (size z) but not always the same, a bit more or a bit less... can't really figure what it is.
About the size fields, they give the final object size after scale factor have been applied. Once again I am not sure about them but i believe the size information could be use as a bounding box and Z position could be a sort of bounding box shift compared to object center. Just some suppositions...
Here is the last version of my object decoder tool :
https://www.dropbox.com/s/bem8k66w8syj80q/sfxObjReader.jar?dl=0Red object : not correctly decoded
Green object : animated
Blue object : position field set
As you may see, the SFX Object decoder do not exactly use the same header decoding as the one explained above, it is just because i tried several test cases and i still don't have figured the real meaning of these fields.
Here is a preview of my project, just a small demo:
https://www.dropbox.com/s/macxo0841djlo5a/sfx_gen.zip?dl=0I started to work on it a long time ago but i can now display direct object from starfox which is awesome =)
Ah yeah, you need a sega megadrive emulator to test it
Edit: fixed dropbox links
Topic: Managed to read Star Fox SNES ROM using VL-Tone guides. I need more info. (Read 101402 times)