SCHG:Sonic the Hedgehog 3 & Knuckles/Level Editing
From Sonic Retro
(Redirected from SCHG:Sonic 3 & Knuckles/Level Editing)
SCHG: Sonic the Hedgehog 3 & Knuckles |
---|
Main Article |
Art Editing |
Editing Art |
Object Editing |
Editing Objects |
Level Editing |
Editing Levels |
Music Editing |
Editing Music |
RAM Editing |
Editing RAM |
Sonic & Knuckles Collection |
Sonic & Knuckles Collection |
Contents
Level ID list
Zone/Act (Hex) | Name/Description |
---|---|
00 00 | Angel Island Zone, Act 1 |
00 01 | Angel Island Zone, Act 2 |
01 00 | Hydrocity Zone, Act 1 |
01 01 | Hydrocity Zone, Act 2 |
02 00 | Marble Garden Zone, Act 1 |
02 01 | Marble Garden Zone, Act 2 |
03 00 | Carnival Night Zone, Act 1 |
03 01 | Carnival Night Zone, Act 2 |
04 00 | Flying Battery Zone, Act 1 |
04 01 | Flying Battery Zone, Act 2 |
05 00 | Ice Cap Zone, Act 1 |
05 01 | Ice Cap Zone, Act 2 |
06 00 | Launch Base Zone, Act 1 |
06 01 | Launch Base Zone, Act 2 |
07 00 | Mushroom Hill Zone, Act 1 |
07 01 | Mushroom Hill Zone, Act 2 |
08 00 | Sandopolis Zone, Act 1 |
08 01 | Sandopolis Zone, Act 2 |
09 00 | Lava Reef Zone, Act 1 |
09 01 | Lava Reef Zone, Act 2 |
0A 00 | Sky Sanctuary Zone, Act 1 |
0A 01 | Sky Sanctuary Zone, Act 2 |
0B 00 | Death Egg Zone, Act 1 |
0B 01 | Death Egg Zone, Act 2 |
0C | The Doomsday Zone |
0D | Ending |
0E | Azure Lake Zone |
0F | Balloon Park Zone |
10 | Desert Palace Zone |
11 | Chrome Gadget Zone |
12 | Endless Mine Zone |
13 | Gumball machine bonus stage |
14 | Magnet ball bonus stage |
15 | Slot machine bonus stage |
16 00 | Lava Reef Zone, boss of Act 2 |
16 01 | Hidden Palace Zone |
17 00 | Death Egg Zone, last two bosses of Act 2 |
17 01 | Hidden Palace Zone, when entered from a giant ring |
Object placement
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 loaded whenever it is in X range regardless of its Y position, 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 the byte $2C of the status table of that object.
Ring placement
There are four bytes for every ring object. The first 2 bytes are X coordinates, and the next two are the Y coordinates. Sonic 3k uses individual rings, unlike Sonic 2, which uses ring groups that have to be expanded into RAM. The advantage of Sonic 3k's method is that ring position data can be read directly from ROM, meaning that only two bytes are used up in RAM per ring instead of six, saving on RAM space and allowing Sonic 3k levels to have a maximum of 511 rings, as compared to Sonic 2's 255, despite allocating $200 bytes less to the ring status table.
The ring placement data must start with 0000 0000, and must end with FFFF. These prevent the rings position checker subroutine from going over the bounds of the ring placement data, and are necessary for the correct functioning of the rings manager.
Level layout
Level layouts are stored uncompressed in the ROM, and the format they use differs significantly from the format used in Sonic 2, allowing much larger levels.
The layout starts with an 8 byte header describing the layout's size. The first word is the foreground width in chunks, the second word is the background width in chunks, the third word is the foreground height in chunks, and the fourth word is the background height in chunks.
Next is a list of 64 word-sized pointers in RAM. Each row of 128x128 tiles has two pointers - one for the foreground data and one for the background data. The maximum level height is thus (64 / 2 * 128) = $1000 pixels, double the maximum level height for Sonic 2. To convert these to ROM addresses, subtract $8000 and add the ROM address for the level layout data.
The actual rows data (beginning at byte $88) is very simple - there is one byte per 128x128 tile, and the blocks are put together from left to right.
16x16 block mappings
16x16 block mappings consist of four 8x8 tiles, arranged in the shape:
0 | 1 |
2 | 3 |
Each 8x8 tile is represented by one word, which like all SEGA Mega Drive 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
128x128 block mappings consist of sixty-four 16x16 tiles, arranged in the shape:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 |
40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 |
48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |
56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
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.
References