Difference between revisions of "Sonic the Hedgehog 2 (Simon Wai prototype)/Level Editing"
From Sonic Retro
(→Level Layout) |
m (→Level Layout) |
||
| Line 23: | Line 23: | ||
Level layouts are not the same as the final. As with Sonic 1, there is a two byte header, with the first byte being width - 1, and the second being height - 1. After that, there is one byte per 128x128 tile to place on the map. The blocks are put together from left to right, top to bottom. | Level layouts are not the same as the final. As with Sonic 1, there is a two byte header, with the first byte being width - 1, and the second being height - 1. After that, there is one byte per 128x128 tile to place on the map. The blocks are put together from left to right, top to bottom. | ||
| − | See the [[SCHG:Sonic 2/Level Specific|level specific hacking info]] for the locations of level layout data. | + | See the [[SCHG:Sonic 2 Beta/Level Specific|level specific hacking info]] for the locations of level layout data. |
== 16x16 Block Mappings == | == 16x16 Block Mappings == | ||
Revision as of 04:46, 14 April 2014
| SCHG: Sonic the Hedgehog 2 (Simon Wai prototype) |
|---|
| Main Article |
| Art Editing |
| Editing Art |
| Object Editing |
| Editing Objects |
| Level Editing |
| Editing Levels |
| Music Editing |
| Editing Music |
| RAM Editing |
| Editing RAM |
| Miscellaneous |
| Miscellaneous Editing |
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 AB00 YYYY YYYY YYYY, where A is the vertical flip flag, B 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, with the most significant bit if set indicating that the object should be assigned an entry on the object respawn table, 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. 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 2/RAM Editing#Object Status Table Format for more info).
Ring Placement
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 Layout
As this is a prototype, Level layouts are decompressed for simpler testing.
Level layouts are not the same as the final. As with Sonic 1, there is a two byte header, with the first byte being width - 1, and the second being height - 1. After that, there is one byte per 128x128 tile to place on the map. The blocks are put together from left to right, top to bottom.
See the level specific hacking info for the locations of level layout data.
16x16 Block Mappings
This data is uncompressed.
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
This data is Kosinski compressed.
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.
Level specific info
See SCHG:Sonic 2/Level Specific