Difference between revisions of "SCHG:Sonic the Hedgehog 3 & Knuckles/Level Editing"
From Sonic Retro
(New page) |
(Adding Object Placement and Ring Placement) |
||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
{{SCHG S3K}} | {{SCHG S3K}} | ||
+ | ==Object Placement== | ||
+ | There are six bites 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 [[SCHG:Sonic 3 & Knuckles/RAM Editing#Object Status Table Format|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 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. | 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. |
Revision as of 03:56, 17 August 2008
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 |
Object Placement
There are six bites 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. The first word of this header is the number of 128x128 tiles that make one foreground row, and the second word is the number of 128x128 tiles that make one background row. The third word is the number of foreground rows, and the fourth is the number of background rows.
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.
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 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
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.