Difference between revisions of "SCHG:Sonic the Hedgehog 3 & Knuckles/Object Editing"
From Sonic Retro
(New page) |
(→Object Placement: Linked) |
||
Line 24: | Line 24: | ||
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. | 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 | + | 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== | ==Ring Placement== |
Revision as of 07:39, 16 July 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 Pointers
Sonic 3 & Knuckles, being a combination of two games, also contains two object pointer lists. The first one is located at $94EA2, and caters to all 1-player Sonic 3 levels as well as Flying Battery Zone, all 2-player zones and all bonus stages. The second one is located at $952A2, and caters to all Sonic & Knuckles levels except Flying Battery Zone and the bonus stages. There are also many objects which are not referenced by either list, since Sonic 3 & Knuckles' method of handling objects means that objects do not necessarily need to be stored in a pointer list to be used by the game. In fact, the only objects stored in the pointer list are those which are part of a level's object placement.
The ID number is in hex, and denotes the object's position in the list (starting from 0). Code is the value of the actual pointer. Note that this is only the starting code pointer, and may change during an object's lifespan. Mappings tells where to find the object's sprite mappings, and Subparameters tells what arguments, if any, the object can take when it's placed on the playfield.
For the first object pointer list, see SCHG:Sonic 3 & Knuckles/Object Editing/Pointer List 1. For the second, see SCHG:Sonic 3 & Knuckles/Object Editing/Pointer List 2. For objects not in either list, see SCHG:Sonic 3 & Knuckles/Object Editing/Other Objects.
Sprite Mappings
Sprite mappings define how to arrange the sprite art. A sprite's mappings begin with an offset table which gives the location of the mappings data for each frame. The actual mappings data consists of a one word header, which gives the number of sprite pieces which make up the frame. Following this header is the actual pieces data, the data for each piece consisting of three words:
- First word:
- High byte is the relative signed top edge position of the sprite from the center of the object.
- Low byte is the size of the sprite, in tiles minus one. The upper four bits are ignored, the next two bits control the width and the lowest two bits control the height. Thus sprites can be of any size from 1x1 tile to 4x4 tiles. For example, $01 is a 1x2 sprite, $02 is a 1x3 sprite, $04 is a 2x1 sprite, and so on.
- Second word:
- This word will be added to the object's VRAM offset and then used as the pattern index for that sprite. Like all SEGA Genesis VDP pattern indices, it 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.
- Third word: This is the relative signed left edge position of the sprite from the center of the object.
Dynamic PLCs
Sonic 3 & Knuckles uses the same DPLC format as Sonic 2: the first word is the number of DPLC requests to make, and each successive word (up to the value of the first word) is split up so that the first nybble is the number of tiles to load minus one, and the last three nybbles are the offset (in tiles, i.e. multiples of $20 bytes) of the art to load from the beginning of the object's specified art offset in ROM. Therefore, in order to request x tiles to be loaded, you need 1+floor(x/16) words in the DPLC.
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.