SCHG:Sonic the Hedgehog 3 & Knuckles/Object Editing
From Sonic Retro
Revision as of 04:36, 25 March 2020 by Black Squirrel (talk | contribs) (Text replacement - "__NOTOC__ {{SCHG S3K}} ==" to "{{SCHG S3K}} ==")
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
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 six bytes (or three words):
YY SS VV VV XX XX
- First word (YY SS):
- YY (Y Position) is the relative signed top edge position of the sprite from the center of the object.
- SS (Shape/Size) 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 (VV VV):
- (VDP/V-Ram read/settings) 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 (XX XX):
- (X Position) This is the relative signed left edge position of the sprite from the center of the object.
Dynamic PLCs
Player Characters
Sonic 3 & Knuckles uses the same DPLC format as Sonic 2 for the main characters: 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.
Other objects
For other objects, the first word is the number of DPLC requests to make minus one, and each successive word (up to the value of the first word plus one) is split up so that the last nybble is the number of tiles to load minus one, and the first 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.
References