[MainMemory]

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.

This post has been edited by MainMemory: 12 July 2012 - 08:17 PM

[Alriightyman]

Sound interesting.. I think I'll give it a whirl, after I am done with this Summer session of University.

[MainMemory]

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

[MainMemory]

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

[Hivebrain]

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.

[MainMemory]

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?

This post has been edited by MainMemory: 02 November 2012 - 10:07 PM

[Hivebrain]

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.

[MainMemory]

I can't imagine why any game wouldn't store that data like that, since it's the standard format.

Hivebrain, on 02 November 2012 - 09:44 PM, said:

This is a nice idea. It'll make future mappings editors easier to program if there's a 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):

byte_7E2C:	spriteHeader
byte_7E2E EQU *+1
	spritePiece	-3, -$C, 1, 1, $11, 0, 0, 0, 0
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...