SonED2 Manual/Art Importing

Main Article Art Importing Data Setup Notes E02 Export Image Export Level Editor Object Editor Project Files Project Types Tile Editor
See Also
SonED2

One key feature of SonED2 is the ability to import palettes and art from image files. This allows the creation of level art in external programs. The "Import from Image" option in the "File" menu contains selections to import a palette, or any of the 3 tile sizes. Palette importing uses a submenu, requesting a "Source ID" (where the colors start on the image's palette), a "Destination ID" (where the colors should start in the level's palette), and the number of color entries that should be copied. A file selection box will appear for all import options, requesting the location and name of the file that contains the data to import. Once the file is selected, the import begins. For Tiles, Blocks, and Chunks, the Status Window will announce the beginning and end of the import process, as well as give the number of tiles that were previously stored in the level, and the number of tiles that are stored after the import has completed.

Two near-identical "from-scratch" example projects are included in the "Example" folder (one for Sonic 1, and one for Sonic 2), along with the source image. The data files are ready for inserting into a game, and can be "played". To re-create them from the source image will require a little work in all editor modes.

There are a few things to bear in mind when creating art externally.

Not following these rules will likely cause undesired results:

SonED2 can read 256-color PCX images of any size, if both the height and width are even. It is preferred that the height and width be equal to each other, however.

The Megadrive/Genesis uses a 64-color palette. The palette itself is divided into 4 rows, each of which may only be used one at a time. This is because each pixel in an 8x8 tile is stored as a 4-bit value, with a maximum value of 15, which is an index into a palette row containing 16 colors (0-15), with color 0 on each row being "transparent" (it is not drawn). The total number of colors that can be generated is 512, which is less than the total number that can be generated by a PC. This is because color components are also stored as 4-bit values, and only even values are used (0, 2, 4, 6, 8, 10, 12, 14). Most art programs use an 8-bit value (0-256) for the Red, Green, and Blue components of a color. Both have the same color range, but the Genesis has significantly fewer shades in-between. It's 4-bit component values correspond to multiples of 32 in the 8-bit component values. Anything in-between would be rounded down to the nearest multiple of 32, meaning that shades that are too similar will become the exact same color. For that reason, a chart containing all 512 possible colors is included in the file "MDColor.png". Using this chart to select colors will help eliminate bad color value problems.

All game art is stored as 8x8 tiles, which are used by "mappings" to build larger images. In the case of level art, 8x8 tiles are mapped into 16x16 Blocks, which are then mapped into the 128x128 (Sonic 2 type) or 256x256 (Sonic 1 type) Chunks that make up the levels. The "mappings" contain the palette row identifier, so a single tile may be reused several times with different palette rows to show the same form with different colors. When importing Blocks or Chunks, SonED2 will use the last pixel found within a tile to determine which palette row to assign it within the Block. If colors from different rows are used within the tile, they will become colors from the row assigned to the tile (the same row entry as in the row they were taken from). The very first color in the 64-color palette (entry 0) is safe to use anywhere in any tile to represent transparency, however.

Some art programs do strange things with the palette, such as not allowing the user to specify which palette index to draw with if two palette entries contain the exact same color (For example, if entry 4 and entry 17 contain the exact same color, attempting to draw with entry 17 will actually draw with entry 4, which can be seen by then changing the color in entry 4). This can be avoided by changing one of the colors completely, or just slightly, so that there is no reason not to use the selected color, and then changing it back when finished drawing. The same error can occur when copying art from one image to another, and will occur if a palette is loaded with a "Match Nearest Color" option. It is always a good idea to double-check the image to make sure that the graphics program hasn't caused any palette errors. Also, Color Reduction options will re-order the palette, so they should only be used outside of any primary images, where the palette and art intended for import are being built and stored.

It is best to use an art program that has a resizeable grid. Using the grid will help ensure that all patterns are drawn in sizes that are multiples of 8, and that art that is moved or pasted is positioned properly. If the art doesn't fit properly into the 8x8 grid, extra tiles will be created, reducing the amount of tiles that can be added later. Larger shapes that form Blocks and Chunks also need to conform to a grid. Blocks should be positioned on a 16x16 grid, and Chunks should be positioned on a 128x128 (Sonic 2 type) or 256x256 (Sonic 1 type) grid. If the tiles are not positioned properly in the image, they will not be imported properly, because the program cannot otherwise know where the tile begins and ends.

SonED2 will attempt to "optimize" tile usage by automatically detecting "mirrored" and/or "flipped" Tiles and Blocks. When an 8x8 or 16x16 shape is encountered that can be displayed by changing the direction of a Tile/Block that has already been stored is found, that tile is not stored, but instead, the previously stored version is used to build the Block or Chunk that is currently being imported, and the proper drawing direction flags are set. When importing art that looks the same as art that is already stored, but should contain different property settings, a new entry is NOT made for the similar tile, because SonED2 cannot know that different properties are required when it is reading an image file that does not contain them. The tile must be copied within the editor, and the appropriate properties set. Art that is already stored with properties set, when run through the import function again, will not be stored in new entires with no properties set, but will use the art that was already stored, with the properties that were already set. If more than one entry that looks the same is already stored, the art being read will be read as the first entry that is found, so if it should actually correspond to a later entry, it must be corrected manually within the editor. This could also cause unnecessary "copies" of larger tile types, so it is recommended that art that has already been imported not be included with any new art intended for import.

Sonic 2 type games use 2 solidity paths and a path swapper object to accomplish loops, however, Sonic 1 types use a single path, and a pre-programmed Chunk test. Each level in a Sonic 1 type game can be given two Chunk IDs to define as "loops". These chunks must have a visibly identical copy immediately following themselves, with the original having solidity filled in on the right half, and the copy having solidity filled in on the left half. (For example, if Chunks 4 and 8 are "loop" chunks, they must contain solidity on the right side, and must also have copies in Chunks 5 and 9, with solidity on the left side). The original and copy are swapped back and forth in-game depending on which side the player is moving toward them from.