Sonic the Hedgehog 2 (16-bit)/Level Editing
From Sonic Retro
| Sonic Community Hacking Guide|
Sonic the Hedgehog 2 (16-bit)
There are six bytes in one object definition. The first two bytes are the X position of the object. The next two bytes, broken down in bits, have the format ABC0 YYYY YYYY YYYY, where A is a flag which if set indicates that the object should be assigned an entry on the object respawn table, B is the vertical flip flag, C is the horizontal flip flag and YYYY YYYY YYYY is the Y position of the object. The 5th byte is the reference number on the object pointer list (see above), and the 6th byte is an optional declaration to use for defining that object's behavior and/or animation. This will depend on the object. See the level specific hacking info for the locations of the object lists.
The 6th byte, the object subtype, is loaded in byte $28 of the status table of that object (see SCHG:Sonic the Hedgehog 2 (16-bit)/RAM Editing#Object Status Table Format for more info).
There are four bytes for every ring object. The first 2 bytes are X coordinates, after that there is one nibble to determine how many rings, then three nibbles (or one nibble and one byte) for the Y coordinates. After you are done adding all your rings for the level, "FF FF" will end the ring data. A format would look like this:
XX XX TY YY
Where X represents X position, Y represents Y position, and T represents type, as per the table below.
Example: 03 46 10 2B
If you see this, then you will get two horizontal rings at X = 0346 Y = 02B. The "1" determines how many rings there are, and in which direction they go (horizontal or vertical). For the "T" nybble, the entry will create a column of rings if the uppermost bit is set, otherwise it will create a row of rings. The number of rings created is the lower 3 bits plus one. Therefore, you can get one to eight rings in a row or column with one ring entry. Notice that types 0 and 8 are the same, as a row of one ring is the same as a column of one ring.
See the level specific hacking info for the locations of the ring data.
Level layouts are compressed in Kosinski format, so to edit them you will need to decompress them first. (I recommend using TSDC for this)
Level layouts are pretty simple. There is one byte per 128x128 tile to place on the map. The blocks are put together from left to right, top to bottom. Each horizontal row is 128 bytes long ($80), and there are 16 rows each for foreground and background (32 total). The rows are interlaced between the foreground and the background, so that there are 128 bytes for the first row of the foreground, then 128 bytes for the first row of the background, then 128 bytes for the second row of the foreground, etc.
See the level specific hacking info for the locations of level layout data.
16x16 Block Mappings
This data is Kosinski compressed.
16x16 block mappings consist of four 8x8 tiles, arranged in the shape:
Each 8x8 tile is represented by one word, which like all SEGA Genesis VDP pattern indices, is a bitmask of the form PCCY XAAA AAAA AAAA. P is the priority flag, CC is the palette line to use, X and Y indicate that the sprite should be flipped horizontally and vertically respectively, and AAA AAAA AAAA is the actual tile index, i.e. the VRAM offset of the pattern divided by $20.
128x128 Block Mappings
This data is Kosinski compressed.
128x128 block mappings consist of sixty-four 16x16 tiles, arranged in the shape:
Each 16x16 tile has a two-byte value with the format SSTT YXII IIII IIII. SS is the solidity of the tile in the alternate collision layer - 00 means not solid, 01 means top solid, 10 means left/right/bottom solid, and 11 means all solid. TT is the solidity of the tile in the normal collision layer - 00 means not solid, 01 means top solid, 10 means left/right/bottom solid, and 11 means all solid. Y is the Y-flip flag, X is the X-flip flag, and II IIII IIII is the index of the 16x16 tile to use.
Level specific info