SonMapEd (Sprite Mappings Editor)

Get SonMapEd 1.05 here. Some peripheral features are missing or incomplete, but it's decently functional as it is. Read this for the basic idea of this program if you don't know what I'm talking about. No support for animations has been added yet, but one possible surprise is I added a ROM extracter dialog so you can load things (including compressed graphics) straight from a ROM, along with preset locations to choose from for certain ROMs as decided by the included offsets.txt file. You can use it with SMD format ROMs and locked-on ROMs too.

I have no documentation for it, but familiarize yourself with the menus and you'll know most of the available commands. You should be able to do most things with the keyboard alone once you know the menu shortcuts well enough. Only the mouse-using commands for adding piecs or selecting tiles are not in the menu. To add a sprite piece, click on the start tile at the bottom, then click on a pattern on the top left. It will advance the appropriate number of tiles forward so you can usually add the next piece without choosing a tile again. Shift+Click to go backward instead of forward. Right click instead of left click to advance the selected tile without actually adding a sprite piece. Use the arrows keys (hold Shift for more precision) to reposition the active sprite piece. You can also select multiple tiles. Ctrl+Click selects or deselects multiple noncontiguous tiles, Shift+Click selects or deselects multiple contiguous tiles. There is no support for clicking on sprites or sprite pieces on the top-right, use their menu shortcut keys([] and ;') to move between them. There is no standard Undo, but there are emulator-style savestate slots to save or load the state of everything loaded in the program.

I suggest pressing O after you load tile graphics to choose the orientation that looks clearest. To scroll up and down (or left and right) if the tiles don't all fit in the window, hold Ctrl+PageDn or Ctrl+PageUp. If you want to scroll less than a single tile (offset < 0x20) you can use the ROM extracter to load the graphics at a different offset. Everything in the "Transformation" menu applies context-sensitively to the selected sprite piece or to the entire sprite depending on if you have a single piece selected or the whole sprite, including movement and horizontal and vertical mirroring of the entire sprite.

You can choose between binary or asm format for saving graphics, mappings, and dynamic reloading cues, simply by saving it with a .asm filename extension if you want it in asm format. Sonic 1/2/3K are supported for saving and loading, with experimental (read: probably broken) Crackers support. That means you can open a Sonic 3 sprite, change the mode to Sonic 1, and save as a Sonic 1 sprite, to get instant conversion between games. Palette rearrangement is also supported, with or without changing the image to match the new palette. You will have to remember to save each type of data file individually to the appropriate places after you make changes, there is no "save everything to where I loaded it from" feature. (However, you can approximate this by making a batch file to copy save state files to locations of your choosing.)

If you've any questions on how to use it, that I didn't already answer, post them here.

 

I don't know what files you've loaded there (a Tails you have put in Sonic 1?) but Dynamic PLC does work for Sonic in Sonic 1, Sonic and Tails in Sonic 2, and Sonic and Tails in Sonic 3.

 

I put together a set of files to load for Tails in Sonic 1 format: here. You could see how they differ from your own. [I initially cut off the tile data 0x20 bytes too early; re-download it if you see any red stripes.]

 

Look in the offsets.txt file, it says it's incomplete (basically an example) and where that data came from. You are free to edit it to make it complete, I don't know where all the stuff in the S3&K ROM is.

 

Oh, okay. In that case you have to choose Sonic 2 mode before you load the dPLC, even if the other mappings are in Sonic 1 mode (you probably realized that too).

 

You can create sprite mappings for it to a new frame, then use Export Sprite, edit the full picture in MSPaint, then Import Sprite. If you can find sprite mappings in the ROM for it you don't have to create them, but there is possibly no sprite corresponding with the title screen art. It's more inconvenient if you don't have the sprite mappings, but this is a sprite mappings editor, not a non-sprite tile patterns editor.

This is intended for use with a split disassembly, not for editing a ROM in place. The program can't save ROMs because it does not edit ROMs. The ROM import is sort of a bonus feature, to aid with moving stuff from another game into your disassembly. However, if you know what you're doing, you should have no trouble "uploading" data to the game after saving it in binary format.

 

Sure you can. Delete Sprite, Select Unused Tiles, Delete Selected Tiles. You can insert new empty sprites in their place if you want the indexes of the following sprites to stay the same.

If "somewhere else" is another Sonic game then simply append its art to the tile graphics (this feature is missing so just copy-paste in a hex editor) before using it to make mappings. If you only have a bitmap file of spindash images, that's what Import Spritesheet is for, but that feature is incomplete so you can instead append dummy tile data for your mappings and later use Import Sprite. Now to make the actual mappings, that's a click-click-done type of operation, especially for something as simple in shape as a spindash.

I can think of some ways to make it marginally easier, but I'm interested to hear how you think this importing process should ideally work, what inputs you would like to be able to give to merge in the spindash.

Why would you need to do that?

Something like this, which becomes this. As you can see, it says "incomplete" for a reason.

 

I wouldn't want it doing such a thing for me, but I see no harm in making it optional.

It's already on my todo list, but I consider it a "peripheral feature", not necessary for anything. More important to me is being able to rearrange small groups of tiles to change what height of piece size they will fit inside, then maybe an auto arrange feature.

It can't account for that when you do it manually, although I meant you won't run into that problem if you add them to the end. Deleting tiles correctly updates the tile numbers and inserting will likewise when I add it.

 

I think you are doing nothing wrong and SonMapEd is somehow forgetting to output the player-2 mappings data. Sorry. See if this works:

Code (Text):

1. ; --------------------------------------------------------------------------------
2. ; Sprite mappings - output from SonMapEd - Sonic 2 format
3. ; --------------------------------------------------------------------------------
4.  
5. SME_oDnhz: 
6.         dc.w SME_oDnhz_2-SME_oDnhz 
7. SME_oDnhz_2:    dc.b 0, 5  
8.         dc.b $F4, $D, 0, $11, 0, 8, 0, 0   
9.         dc.b $F4, $D, 8, $11, 8, 8, $FF, $E0   
10.         dc.b 4, 9, 0, $21, 0, $10, $FF, $E0
11.         dc.b 4, 9, 8, $21, 8, $10, 0, 8
12.         dc.b 4, 5, 0, $1B, 0, $D, $FF, $F8 
13.         even

[This is a bug in the ASM exporter, so if you save it as BIN and incbin that file it should work. Or download the newer version where the bug is fixed.]

 

Because I was an idiot and disabled some code I shouldn't have. Here's version 1.01, fixes that bug and a crashing bug if you add a sprite piece with 0 sprites, and adds some KosinskiM support I forgot about.