don't click here

Sprite Mappings Macros

Discussion in 'Engineering & Reverse Engineering' started by MainMemory, Jul 9, 2012.

  1. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,742
    338
    63
    SonLVL
    I've created a set of macros in an attempt to produce mapping files that can be read and edited by humans. Of course, program support for these is currently lacking, but I may do something about that in the future.

    In order to use these you will have to define a SonicMappingsVer constant equal to 1, 2 or 3 depending on the game you're editing, and include SpritePiece.asm.

    You can find the asm file containing the macros here, a sample converted file here, and a converter program (with SpritePiece.asm file) here.

    About the "spritePiece2P" macro: that's only needed if you're editing Sonic 2 and your sprites use the same mappings but a different art tile in 2P mode, otherwise the 2P data will be automatically calculated.

    Edit: updated to use "mappingsTable"/"mappingsTableEntry" macros instead of "dc.w piece-main" statements.
     
  2. Alriightyman

    Alriightyman

    I am back... from the dead! Tech Member
    357
    11
    18
    Somewhere in hot, death Florida
    0101001101101111011011100110100101100011 00000010: 0101001100000011 01000101011001000110100101110100011010010110111101101110
    Sound interesting.. I think I'll give it a whirl, after I am done with this Summer session of University.
     
  3. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,742
    338
    63
    SonLVL
    Updates:
    • SpritePiece.asm now includes DPLC macros (with special macros for S3K player DPLCs)
    • A new DPLC converter, and commandline mappings and DPLC converters
    • The converters can now read macro'd ASM files (and SonLVL will next update)
    • Converters can export to binary, regular ASM, or ASM with macros
     
  4. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,742
    338
    63
    SonLVL
    Bumping this to let you know that I've updated the programs with the latest SonLVL API (pretty sure the old one had bugs), and the converter package now includes separate SpritePiece ASM files for AS (S2, S3K) and now ASM68K (S1).
     
  5. Hivebrain

    Hivebrain

    Administrator
    3,049
    161
    43
    53.4N, 1.5W
    Github
    This is a nice idea. It'll make future mappings editors easier to program if there's a standard format.

    It might be better if the last four parameters (xflip,yflip,pal,pri) were optional, and merged into one. So you'd have xflip+yflip+usepal2+high or something as the last parameter if needed. It would improve readability not having several 0s on every sprite.
     
  6. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,742
    338
    63
    SonLVL
    Do both AS and ASM68K support optional parameters? Or would this be more like arttile+xflip+yflip+usepal2+high?

    Besides, it's a little late to change the format now, we'd have to edit all the mappings in the Sonic 1 disassembly, Sonic 2 disassembly, my hacks, anyone else that's used the converter, and SonLVL's parser. I could try to make all my current and future programs backwards compatible, but is it really worth it?
     
  7. Hivebrain

    Hivebrain

    Administrator
    3,049
    161
    43
    53.4N, 1.5W
    Github
    You can have optional parameters in ASM68K by using "if narg=" in macros. The idea was to have two separate parameters, one for the tile and one for the optional stuff.

    Thinking about it now, it wouldn't work to combine them if there are games that don't store that data in the same way as Sonic games.
     
  8. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,742
    338
    63
    SonLVL
    I can't imagine why any game wouldn't store that data like that, since it's the standard format.
    Also, being able to read mappings from the text directly is a nice idea, but it doesn't work, because mappings are often optimized, and in order to be included in the repository, the mappings have to create output identical to the originals. So you end up with things like this (from _maps/Spiked Pole Helix.asm):
    Code (Text):
    1. byte_7E2C:  spriteHeader
    2. byte_7E2E EQU *+1
    3.     spritePiece -3, -$C, 1, 1, $11, 0, 0, 0, 0
    4. byte_7E2C_End
    So in order to read this file you have to convert the asm to binary (and implement the EQU directive and * symbol) and read the binary into whatever data structures your program uses. And then there's mappings that refer to frames in another mapping set, two (or more) mappings that have their tables one after the other with a common set of frames...