Differences

This shows you the differences between two versions of the page.

--- ff3:ff3us:tutorial:sprites [2017/09/01 14:15]
madsiur [Character Sprites and Portraits Editing]
+++ ff3:ff3us:tutorial:sprites [2019/02/12 11:12] (current)
@@ Line 16: / Line 16: @@
 **Skip this section if you don't want to read about the technical side of sprites.  The rest of this tutorial will refer back to this section, but it will be restated in simpler terms.  Don't worry too much if you don't understand this part**
-SNES sprites are the combination of two elements: graphic data (GFX) and a palette. The GFX can have a different maximum number of colors, which is called the graphic format. Most SNES graphics are 4bpp (4 bits per pixel), meaning they can have a maximum of 16 colors (transparency color + 15 colors). There are only 16 possible numbers that can be represented with 4 bits (0 to 15).  Listed out in binary, these numbers are 0000, 0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000, 1001, 1010, 1011, 1100, 1101, 1110 and 1111. However, there are game GFX that can be 3bpp (8 colors maximum), like some monsters, or 2bpp (4 colors maximum), like the fonts. In the case of 3bpp format, it is always converted by the code to 4bpp because the hardware cannot display it. The 3bpp is a form of compression.
+SNES sprites are a combination of two elements: graphic data (GFX) and a palette. The GFX can have a different maximum number of colors, which is called the graphic format. Most SNES graphics are 4bpp (4 bits per pixel), meaning they can have a maximum of 16 colors (transparency color + 15 colors). There are only 16 possible numbers that can be represented with 4 bits (0 to 15).  Listed out in binary, these numbers are 0000, 0001, 0010, 0011, 0100, 0101, 0110, 0111, 1000, 1001, 1010, 1011, 1100, 1101, 1110 and 1111. However, there are game GFX that can be 3bpp (8 colors maximum), like some monsters, or 2bpp (4 colors maximum), like the fonts. In the case of 3bpp format, it is always converted by the code to 4bpp because the hardware cannot display it. The 3bpp format is a form of compression.
 {{  ff3:ff3us:tutorial:sprites:terra-bpp.png?nolink  }}
-To picture a GFX, imagine (in the case of a 8x8 4bpp graphic) an 8x8 array or table where each pixel is represented by a number from 0 to 15. In a "normal" 4bpp format, one byte (8 bits) would hold 2 pixels represented by 4 bits each, so 2 pixels would fit in one byte. Instead of an array of 64 bytes (which you'd get if your GFX format only stored one pixel in each byte), your GFX would be stored in 32 bytes since 2 pixels fit in one byte. For example, a byte such as 00000010 is the combination of 0000 (0) and 0010 (2). Therefore, this byte contains a pixel of color 0 and a pixel of color 2. This is the logic way and the Bitmap class of Microsoft work this way, as the following image show. Let's take the following tile with the following palette:
+To picture a GFX, imagine (in the case of a 8x8 4bpp graphic) an 8x8 array or table where each pixel is represented by a number from 0 to 15. In a "normal" 4bpp format, one byte (8 bits) would hold 2 pixels represented by 4 bits each, so 2 pixels would fit in one byte. Instead of an array of 64 bytes (which you'd get if your GFX format only stored one pixel in each byte), your GFX would be stored in 32 bytes since 2 pixels fit in one byte. For example, the byte 00000010 is a combination of 0000 (0) and 0010 (2). Therefore, this byte contains a pixel of color 0 and a pixel of color 2. This is a logical way to store images, and Microsoft's Bitmap format works this way as well. Let's consider the following tile with the following palette:
 {{ff3:ff3us:tutorial:sprites:tile-draw.png?nolink}}\\
 {{ff3:ff3us:tutorial:sprites:palette-h.png?nolink}}
-The corresponding array with color IDs is same size except each color is replaced by its palette ID (0x00 to 0x0F):
+The corresponding array of color IDs is the same size and represents the same image, except that each color is replaced by its palette ID (0x00 to 0x0F):
 {{ff3:ff3us:tutorial:sprites:tile-pal-1.png?nolink}}
-Normally, in a logic 4bpp format, if we see the same array in color IDs bits now instead of //full number// (integer or hexadecimal), we should have the following, with one byte being made by two side-by-side pixels:
+You would logically expect that if we represented these values as bits instead of integer or hexadecimal values, we would obtain the following set of bytes.  In this image, each byte represents two side-by-side pixels.
 {{ff3:ff3us:tutorial:sprites:tile-bin.png?nolink}}
-However, **bad news!** SNES 4bpp format does not work this way. If we take our happy face tile of 64 pixels (8x8) we get the following 32 bytes, as seen in a Hex editor, 2 rows read from left to right:
+However, **bad news!** The SNES 4bpp format does not work this way. If we take our 64 pixel large (8x8) happy face tile, we get the following 32 bytes as seen in a Hex editor.  Note that the 32 bytes have been arranged into two rows of 16 bytes each for clarity (you'll see why in a moment).
 {{ff3:ff3us:tutorial:sprites:tile-hex.png?nolink}}
-Each pixel row is 4 bytes as in any other 4bpp format, except you have to read the byte in bitplane to get the color IDs. Each pixel row is represented in the following image. As an example, pixel row 0 is bytes 18 00 00 00:
+Each row of pixels is represented by 4 bytes as with any other 4bpp format, except that we have to read the bytes in bitplane to get the color IDs. To read the bytes in bitplane, we first divide the two rows of data into blocks of four bytes as shown.  Each pixel row is represented by a single square in the following image.  For example, pixel row 0 is made up of the bytes 18 00 00 00.
 {{ff3:ff3us:tutorial:sprites:tile-hex-row.png?nolink}}
-Bitplanes are read as 1, 2, 3, 4 or top-left, top-right, bottom-left, bottom-right. We will take row 2 to continue the example.
+Bitplanes are read in the order of b1, b2, b3, b4.  That is, top-left, top-right, bottom-left, bottom-right. We will take row 2 to continue the example.
 {{ff3:ff3us:tutorial:sprites:bitplane.png?nolink}} {{ff3:ff3us:tutorial:sprites:row-1.png?nolink}}
-First, you must see each byte in its binary representation. Here the example is symetric but you would usually read from right to left. Each pixel value of the row is represented by the aligned column of those 4 bytes. As an example for first pixel of the row, you read bitplane 1, 2, 3 and 4 of column of bit 0 which are 0, 0, 0, 0. You color ID is therefore 0000, i.e. palette ID 0.
+First, you must look at each byte in its binary representation. When the four bytes are aligned on top of each other in the following manner, each column represents a pixel.  Here the example is symmetric, but you would usually read from right to left.  For the first pixel of this row, the bits in the column are 0, 0, 0, 0, as shown in the diagram. Your color ID is therefore 0000, (i.e., palette ID 0).
 {{ff3:ff3us:tutorial:sprites:row-2a.png?nolink}} {{ff3:ff3us:tutorial:sprites:row-2b.png?nolink}}
-Since there is 8 bit in 1 bytes, the 8x8 tile format take all its sense here. Here are the color values of row 2. As you can see it correspond what is in our previous color array of the tile.
+Since there are 8 bits in 1 byte (and therefore eight columns), and there are eight pixels in each row, the 8x8 tile format begins to make sense now. Here are the color values of row 2. As you can see, it corresponds to what is in our previous color array of the tile.
 {{ff3:ff3us:tutorial:sprites:row-3.png?nolink}} {{ff3:ff3us:tutorial:sprites:tile-pal-2.png?nolink}}
-The SNES 4bpp format is not made to be easily humanly readable and was made this way because of the hardware. Don't worry if you struggle with this; this is the detailed technical side and mastering it is not required at all to sprite. Same goes for the coming palette description.
+The SNES 4bpp format is not made to be human-readable, and it was made this way because of the hardware. Don't worry if you struggle with this; this is the detailed technical side and mastering it is not required at all to sprite. Same goes for the coming palette description.
 Palettes are a sequence of color data that is "applied" to the GFX. Color 2 of the palette is "applied" to all the pixels of color 2 of the GFX. This method allows us to reuse GFX with different palettes. Palettes are usually 2, 4, 8, 16 or 256 colors (Mode 7), but there is no data in the palette that indicates its length. It is specified in the game code how many palette bytes and GFX bytes to read to correctly display a certain graphic on-screen.
-A SNES Color is in 15 bits RGB format. In short, this mean each color can be represented by 2 bytes (16 bits). Each channel value (R, G or B) is 5 bits long, and the first bit is always 0. Specifically, the format is **0BBBBBGG GGGRRRRR**.  A 5 bit number can be 32 possible values, from 0-31, so there can be 32 different intensities of each of the three primary colors.  Considering every combination of red, blue, and green that a single pixel can have, there are 32 767 possible colors on the SNES (32 x 32 x 32).  More modern color formats like 24 bit RGB and above (1 byte per channel) have a 0-255 range for each color channel. Translated to 24 bits RGB, a SNES color will always end in 0 or 8.  Changing the value of a color by 1 on a 1-31 scale is the same as changing it by 8 on a 0-255 scale. If we use the hex color notation, a valid SNES color expressed in 24 bit RGB could be 18,20,18 (sort of black), but the 24 bit RGB hex color 18,19,18 has no SNES equivalent (0x19 cannot be set on a 0-31 scale because 0x19 is not divisible by 0x08). To be as close as possible, this color should be set as 18,18,18, which is equivalent to 3,3,3 in SNES palette editing programs. Most (if not all) spriting utilities do color //rounding// for you in order to take free edits in Gimp and such into account, so you don't need to worry about the color //rounding// at all.
+A SNES Color is in 15 bit RGB format. In short, this means each color can be represented by 2 bytes (16 bits). Each channel value (R, G or B) is 5 bits long, and the first bit is always 0. Specifically, the format is **0BBBBBGG GGGRRRRR**.  A 5 bit number can be 32 possible values, from 0-31, so there can be 32 different intensities of each of the three primary colors.  Considering every combination of red, blue, and green that a single pixel can have, there are 32 768 possible colors on the SNES (32 x 32 x 32).  More modern color formats like 24 bit RGB and above (1 byte per channel) have a 0-255 range for each color channel. Translated to 24 bit RGB, a SNES color will always end in 0 or 8.  Changing the value of a color by 1 on a 1-31 scale is the same as changing it by 8 on a 0-255 scale. If we use the hex color notation, a valid SNES color expressed in 24 bit RGB could be 18,20,18 (sort of black), but the 24 bit RGB hex color 18,19,18 has no SNES equivalent (0x19 cannot be set on a 0-31 scale because 0x19 is not divisible by 0x08). To be as close as possible, this color should be set as 18,18,18, which is equivalent to 3,3,3 in SNES palette editing programs. Most (if not all) spriting utilities do color //rounding// for you in order to take free edits in Gimp and such into account, so you don't need to worry about the color //rounding// at all.
 {{  ff3:ff3us:tutorial:sprites:terra-rgb.png?nolink  }}
-So we know a SNES color fits into 2 bytes; therefore, a 16 color palette takes up 32 bytes of space in the ROM. This is valid for all SNES games. As quickly mentioned previously, transparency is a color because there is no alpha channel in the 15 bits RGB format. The game determines which color is transparent. In the case of FF6, it is always color 0. So this color in the palette will have a RGB value, but it will be //masked// by the game to show transparency instead.
+So we know a SNES color fits into 2 bytes; therefore, a 16 color palette takes up 32 bytes of space in the ROM. This is valid for all SNES games. As quickly mentioned previously, transparency is a color because there is no alpha channel in the 15 bit RGB format. The game determines which color is transparent. In the case of FF6, it is always color 0. So this color in the palette will have an RGB value, but it will be //masked// by the game to show transparency instead.
-Here is an example in 5 steps how to convert a color to B,G,R format. We will take our precendent palette of the 4bpp example:
+Here is a five step example to show how to convert a color to B,G,R format. We will take our palette from the preceding 4bpp example:
 {{ff3:ff3us:tutorial:sprites:palette-h.png?nolink}}\\
 {{ff3:ff3us:tutorial:sprites:pal-1.png?nolink}}
-We will take the first color, the medium-dark grey. The steps are inverted 2 bytes value to binary, separation in 3 times 5 bits (1 bit not used) and finally conversion to a decimal value between 0 and 31:
+Let's look at the first color: the medium-dark grey. The steps are:
+) Convert the 2 byte value to binary.\\
+) Separate the binary values into three sets of five bits.  The first bit is not used.\\
+) Convert each of the three color values to a decimal value between 0 and 31.\\
 {{ff3:ff3us:tutorial:sprites:pal-2.png?nolink}}\\
@@ Line 75: / Line 79: @@
 {{ff3:ff3us:tutorial:sprites:pal-5.png?nolink}}\\
-Here are the results for the first 8 colors of our palette in R,G,B format:
+Here are the results for the first 8 colors of our palette in B,G,R format:
 {{ff3:ff3us:tutorial:sprites:pal-8.png?nolink}}
-This basically covers the technical side of colors, palettes and GFX. Little of what was explained is mandatory to accomplish everyday spriting tasks like editing a sprite in FF3usME, but I think it is good to understand how these elements work on the byte level. If you are using an utility that lets you import images (.png, .bmp, .gif, .jpg, etc.), you should work in an image editor such as Gimp in the "indexed 16 for 4bpp graphic" format. //Indexed// means that the image data is an array of color IDs as with SNES GFX, and //16// is the maximum number of colors. Depending of what you use, the all purpose image editor may have //Indexed// format only, so you'll need to set the maximum number of colors yourself. This is always a safer approach than editing an image in 32bpp ARGB format and adding too much colors or even transparency.
+This basically covers the technical side of colors, palettes and GFX. Little of what was explained is mandatory to accomplish everyday spriting tasks like editing a sprite in FF3usME, but I think it is good to understand how these elements work on the byte level. If you are using a utility that lets you import images (.png, .bmp, .gif, .jpg, etc.), you should work in an image editor such as Gimp in the "indexed 16 for 4bpp graphic" format. //Indexed// means that the image data is an array of color IDs as with SNES GFX, and //16// is the maximum number of colors. Depending of what you use, the all purpose image editor may have //Indexed// format only, so you'll need to set the maximum number of colors yourself. This is always a safer approach than editing an image in 32bpp ARGB format and adding too many colors or even transparency.
 ==== 3. Editing Tiles (YY-CHR) ====
-If you wish to do simple tile edits, YY-CHR can be a solution. There is a {{ff3:ff3us:util:gfx:yychr_net.zip|.NET version}} and a {{ff3:ff3us:util:gfx:yy-chr20120407_en.zip|C++ version}}. I personally go with the C++ one; it is older, but it has more features that have not yet been ported to the .NET version. The image shown here is from the C++ version.
+If you wish to do simple tile edits, [[rh:utilities:yychr|YY-CHR]] can be a solution. There is a .NET and C++ versions. I personally go with the C++ one; it is older, but it has more features that have not yet been ported to the .NET version. The image shown here is from the C++ version.
-Character sprite are located at $D50000 ($D50200 with header). You can either {{ff3:ff3us:tutorial:sprites:yychr-offset.png?linkonly|enter that address}} (as $150000 or $150200 if header present) or scroll until you see the GFX tiles. Note that you need to  {{ff3:ff3us:tutorial:sprites:yychr-4bpp.png?linkonly|set the graphic format to 4bpp SNES}}.
+Character sprites are located at $D50000 ($D50200 with header). You can either {{ff3:ff3us:tutorial:sprites:yychr-offset.png?linkonly|enter that address}} (as $150000 or $150200 if header present) or scroll until you see the GFX tiles. Note that you need to  {{ff3:ff3us:tutorial:sprites:yychr-4bpp.png?linkonly|set the graphic format to 4bpp SNES}}.
-If you want the right colors (i.e., the right palette), you can import the {{ff3:ff3us:tutorial:sprites:ff3us-pal.zip|FF6 NPC Palettes}} in YY-CHR by going to //Palette -> Open Palette (*.pal)//. This make editing a lot easier, but it is not mandatory.  The palette shown in YY-CHR is not the one used by the game, and the GFX is not modified by this step since it uses a palette (see [[ff3:ff3us:tutorial:sprites#understanding_sprites|section 2]]).
+If you want the right colors (i.e., the right palette), you can import the {{ff3:ff3us:tutorial:sprites:ff3us-pal.zip|FF6 NPC Palettes}} in [[rh:utilities:yychr|YY-CHR]] by going to //Palette -> Open Palette (*.pal)//. This makes editing a lot easier, but it is not mandatory.  The palette shown in [[rh:utilities:yychr|YY-CHR]] is not the one used by the game, and the GFX is not modified by this step since it uses a palette (see [[ff3:ff3us:tutorial:sprites#understanding_sprites|section 2]]).
 There are several different tile arrangements available. Since we are dealing with 16x24 sprites for characters, a more convenient way to view the tiles would be {{ff3:ff3us:tutorial:sprites:yychr-16x24.png?linkonly|16x24}}. If you had a 32x32 NPC sprite to edit, choosing 32x32 for the tile arrangement would make it easier to edit the tiles. As previously stated, other utilities are more useful than YY-CHR. [[ff3:ff3us:util:ff3usme|FF3usME]] and [[ff3:ff3us:util:ff3spriteed|FF3SpriteEd]] both have a tile editor (see {{ff3:ff3us:tutorial:sprites:ff3usme-tile.png?linkonly|here}} and {{ff3:ff3us:tutorial:sprites:ff3usse-tile.png?linkonly|here}}). [[ff3:ff3us:util:ff3se|FF3SE]] only allows sprite sheet editing, but it follows the same tile logic when saving the sprite to the ROM.
@@ Line 93: / Line 97: @@
 {{  ff3:ff3us:tutorial:sprites:yychr.png?nolink  }}
-To summarize this section, YY-CHR can help with basic tasks, but for complex sprite editing, FF3usME, FF3SpriteEd, and FF3SE are more convivial and allow a faster working pace.
+To summarize this section, [[rh:utilities:yychr|YY-CHR]] can help with basic tasks, but for complex sprite editing, FF3usME, FF3SpriteEd, and FF3SE are more convivial and allow a faster working pace.
 ==== 4. Editing Sprites ====
@@ Line 101: / Line 105: @@
 === A. FF3SE (no longer developed) ===
-First up is [[ff3:ff3us:util:ff3se|FF3SE]], which has no tile editor, but allows sprite sheet editing. Its features are more basic than FF3usME or FF3SpriteEd. This can be more difficult to work with if you are a novice and don't know which tiles repeat. Also, there is no way to animate the sprite to see if your work is correct or should be adjusted. Note that there is a "trick" to importing a sprite with the correct palette order every time. You simply have to draw your palette on first pixel row as shown {{ff3:ff3us:tutorial:sprites:terra-import-128.png?linkonly|here}}. This "trick" can be used in FF3usME, FF3SpriteEd, or any editor that determines the palette by scanning the image from the //top-left to the bottom-right//.
+First up is [[ff3:ff3us:util:ff3se|FF3SE]], which has no tile editor, but allows sprite sheet editing. Its features are more basic than FF3usME or FF3SpriteEd. This can be more difficult to work with if you are a novice and don't know which tiles repeat. Also, there is no way to animate the sprite to see if your work is correct or should be adjusted. Note that there is a "trick" to importing a sprite with the correct palette order every time. You simply have to draw your palette on the first pixel row as shown {{ff3:ff3us:tutorial:sprites:terra-import-128.png?linkonly|here}}. This "trick" can be used in FF3usME, FF3SpriteEd, or any editor that determines the palette by scanning the image from the //top-left to the bottom-right//.
 {{  ff3:ff3us:tutorial:sprites:ff3se-char.png?nolink  }}
@@ Line 117: / Line 121: @@
 {{  ff3:ff3us:tutorial:sprites:ff3usme.png?nolink  }}
-To conclude this section, I'll talk about the spritesheet formats. FF3SE exports the sprite sheet in the //old// format, meaning they have no "riding" or "dead" (the sideways dead pose used in battle) poses included. This is also the only format it can import. FF3usME uses a similar (but newer) format that includes the dead and riding poses. Lord J's editor can import / export in either the //old// or //new// format, making FF3usME more versatile than FF3SE or FF3SpriteEd.
+To conclude this section, I'll talk about the spritesheet formats. FF3SE exports the sprite sheets in the //old// format, meaning they have no "riding" or "dead" (the sideways dead pose used in battle) poses included. This is also the only format it can import. FF3usME uses a similar (but newer) format that includes the dead and riding poses. Lord J's editor can import / export in either the //old// or //new// format, making FF3usME more versatile than FF3SE or FF3SpriteEd.
 {{ff3:ff3us:tutorial:sprites:terra-me-old-300.png?nolink  }} {{ff3:ff3us:tutorial:sprites:terra-me-new-332.png?nolink}}
@@ Line 127: / Line 131: @@
 {{ff3:ff3us:tutorial:sprites:sp-00-pose-00.png}}{{ff3:ff3us:tutorial:sprites:sp-01-pose-00.png}}{{ff3:ff3us:tutorial:sprites:sp-02-pose-00.png}} {{ff3:ff3us:tutorial:sprites:terra-pose-00.gif}}
-[[ff3:ff3us:util:ff3usme|FF3usME]] has 2 kind of animation: //three pose animations// following a 1-2-1-3 pattern and //two pose animations// following a 1-2 pattern. There are 5 //three pose animations// and 12 //two pose animations//. A FF3usME animation table and pose table with corresponding tile IDs (on images) are available:
+[[ff3:ff3us:util:ff3usme|FF3usME]] has 2 kind of animation: //three pose animations// following a 1-2-1-3 pattern and //two pose animations// following a 1-2 pattern. There are 5 //three pose animations// and 12 //two pose animations//. An FF3usME animation table and pose table with corresponding tile IDs (overlaid on images) are available:
 [[ff3:ff3us:tutorial:sprites:animation|FF3usME animations table]]\\
@@ Line 133: / Line 137: @@
-For a short description of each pose ID, refer to the [[ff3:ff3us:doc:asm:codes:movement_codes|movement action codes]] used in the action queue of characters in the event code.
+For a short description of each pose ID, refer to the [[ff3:ff3us:doc:asm:codes:movement_codes|movement action codes]] used in the action queues of characters in the event code.
-The possible animations and pose patterns are used mainly in the event code (as well as battle module and world map module). For events, you can call a pose in an action queue of a character or NPC (event commands $00-$35). Walking combinations have their own [[ff3:ff3us:doc:asm:codes:movement_codes#movement_actions_80-ab|set of movement actions ($80-$AB)]]. You can call a single pose in an event queue with [[ff3:ff3us:doc:asm:codes:movement_codes#graphical_actions_00-7f|graphical action $00-$7F]]. Actions $00-$3F are can be view in FF3usME for the most part and $40-$7F is the horizontal flip of $00-$3F.
+The possible "animations" and poses are used mainly in the event code (as well as the battle module and the world map module). For events, you can call a pose in the action queue of a character or NPC (event commands $00-$35). Walking combinations have their own [[ff3:ff3us:doc:asm:codes:movement_codes#movement_actions_80-ab|set of movement actions ($80-$AB)]]. You can call a single pose in an event queue with [[ff3:ff3us:doc:asm:codes:movement_codes#graphical_actions_00-7f|graphical action $00-$7F]]. Actions $00-$3F can be viewed in FF3usME for the most part, and actions $40-$7F are the horizontally flipped versions of $00-$3F.
-There is an "unused" pose on the spritesheet that can be used. Terra is the only one having a valid sprite for it. It's the last pose before the tent in FF3usME, usually filled with the original FF6 spriter signature.
+There is an "unused" pose on the spritesheet that can be used. Terra is the only one who has a valid sprite for it. It's the last pose before the tent in FF3usME, usually filled with the original FF6 spriter signature.
-If we come back to spriting, is it important to make sure all the edited poses work correctly with the sprites animations shown in FF3usME. Editing a tile can sometime have an effect on a pose we did not suspected at first glance. Get used to the tile sharing of the sprite poses, that is the same if we look at all sprite sheets of the same size.
+If we come back to spriting, is it important to make sure all the edited poses work correctly with the sprite animations shown in FF3usME. Editing a tile can sometime have an effect on a pose we did not expect at first glance. Get used to the tile sharing of the sprite poses; it works this way for all sprites of the same size.
 ==== 6. Editing Palettes ====
-One of the biggest puzzle for those who have sprite with different palette is making sure everything fit together. Why? Because sprite share palettes! As an example, if you change Celes hair color to blue, Sabin, Edgar and Leo's hair will be blue.
+One of the biggest puzzles for those who have sprites with different palettes is making sure everything fits together. Why? Because sprite share palettes! For example, if you change Celes' hair color to blue, Sabin, Edgar, and Leo will all have blue hair.
 {{  ff3:ff3us:tutorial:sprites:same-hair.png?nolink  }}
-Also there are two 16 colors palettes assigned for each character, one palette for battle and one for maps and overworld. Most of the time they match but they are exceptions. There are 8 battle palettes (located at $ED6300) and 32 overworld palettes (located at $E68000). Here are the first 7 of each type:
+Also, there are two 16 color palettes assigned to each character: one palette for battle and one for the maps/overworld. Most of the time they match, but there are exceptions. There are 8 battle palettes (located at $ED6300) and 32 overworld palettes (located at $E68000). Here are the first 7 of each type:
 {{ff3:ff3us:tutorial:sprites:pal-ow.png}} {{ff3:ff3us:tutorial:sprites:pal-bt.png}}
-They are both assigned in a different way. The battle palette  is assigned via a table of 26 one byte entries for the palette ID (14 first entries being the main cast in regular order). This table is located at $C2CE2B. As for the overworld palette it is assigned by event usually when recruiting the character. //Map characters// are reused, as an example character $07 is first a moogle, then a ghost to finally become Strago. There is many palette assignations needed in a case like this.
+They are each assigned in a different way. The battle palette is assigned via a table of 26 one byte entries for the palette ID.  The first 14 entries are the main cast in regular order. This table is located at $C2CE2B. As for the overworld palette, it is assigned by event, usually when recruiting the character. //Map characters// are reused; for example, character $07 is a moogle and a ghost before finally becoming Strago. This means that character $07 has their palette changed several times over the course of the game.
-This {{ff3:ff3us:doc:game:palette_locs.zip|palette and sprite changes document}} made by runelancer is quite handy to find which event code need to be changed. Check also {{ff3:ff3us:doc:game:command_list.zip|Lockirby's Event Document}} for the use of command $43 that change the palette. As an example if you want to set Locke to palette 05, the command would be 43 01 05, because Locke is actor 01.
+This {{ff3:ff3us:doc:game:palette_locs.zip|palette and sprite change document}} made by runelancer is quite handy to find what event code needs to be changed when you want to change a character's palette. Also check out {{ff3:ff3us:doc:game:command_list.zip|Lockirby's Event Document}} for the use of command $43 that changes the palette. For example, if you want to set Locke to palette 05, the command would be 43 01 05 because Locke is actor 01.
-While there are many overworld palettes all regular characters and //character NPCs// use a palette ID between 0 and 5, with exception of Esper Terra that use overworld palette 8 and battle palette 6. The reason for you being unable to use 6 and 7 is due to those palettes not being able compatible with save/store/character selection screens. For NPCs, the palette ID is located in the NPC data, it's something that can be edited easily with {{ff3:ff3us:util:maps:ff6le_rogue_2013-05-25.7z|FF6LE}}. Here are two tables of the palettes used by the main sprites and main NPCs. Some NPCs can be used with different palettes such as most generic NPCs, however they only appear in the table with their default palette.
+While there are many overworld palettes, all regular characters and //character NPCs// use a palette ID between 0 and 5, with the exception of Esper Terra who uses overworld palette 8 and battle palette 6. The reason for you being unable to use 6 and 7 is due to those palettes not being compatible with the save/shop/character selection screens. For NPCs, the palette ID is located in the NPC data.  It's something that can be edited easily with {{ff3:ff3us:util:maps:ff6le_rogue_2013-05-25.7z|FF6LE}}. Here are two tables of the palettes used by the main sprites and main NPCs. Some NPCs can be used with different palettes (such as most generic NPCs), but they only appear in the table with their default palette.
 **Overworld palette**
 |  Palette ID  |Sprites using the palette|
 |  00  |Edgar, Sabin, Celes, Imp, Leo, Ghost, generic elder, generic man, Maria, Rachel|
-|  01  |Locke, Imperial, Merchant, Scholar, Returner, Clyde, generic woman, generic boy, generic girl, Narshe guard, sailor|
+|  01  |Locke, Imperial, Merchant, scholar, Returner, Clyde, generic woman, generic boy, generic girl, Narshe guard, sailor|
-|  02  |Terra, waitress, Figaro Sergent, Figaro Guard, Katarin, Darryl|
+|  02  |Terra, waitress, Figaro sargent, Figaro guard, Katarin, Daryl|
 |  03  |Strago, Relm, Gau, Gogo, Banon, Kefka, Gestahl, Gau (suit), Cid, generic thief|
 |  04  |Cyan, Shadow, Setzer, Interceptor, Draco, Arvis, Matron, pigeon, maestro, Maduin, Vargas|
@@ Line 173: / Line 177: @@
 |  Palette ID  |Sprites using the palette|
 |  00  |Edgar, Sabin, Celes, Imp, Leo, Ghost, generic elder, generic man, Interceptor|
-|  01  |Locke, Imperial, Merchant|
+|  01  |Locke, Imperial Soldier, Merchant|
 |  02  |Terra|
 |  03  |Strago, Relm, Gau, Gogo, Banon, Kefka, Gestahl|
@@ Line 180: / Line 184: @@
 |  06  |Esper Terra|
-Finally when you edit your sprite and colors, there is an order to respect. One of the reason is explained in next section and also why you can only use the first 12 colors for a battle sprite:
+Finally, when you edit your sprite and colors, there is an order to respect. One of the reasons is explained in next section along with the reason why you can only use the first 12 colors for a battle sprite:
 |  Color ID  |Description  |
 |  00  |transparent  |
@@ Line 197: / Line 201: @@
 ==== 7. Other Specifications ====
-=== A) You can set different sprite for battle and overworld ===
+=== A) You can set different sprites for battles and the overworld ===
-While the vanilla game has same sprite for battle and NPC or overworld PC, you could set a different sprite for battle. The game get a sprite GFX index for each battle sprite in a pointer table at $C2CE43. Each entry is 3 bytes and there are 24 entries. As for NPCs, this is also in the NPC data which can be edited with FF6LE. Finally playable characters get their GFX set with an event command in the same way the palette is assigned, except it is with event command $37.
+While the vanilla game has the same sprites for battle and NPCs or overworld PCs, you could set a different sprite for battle. The game gets a sprite GFX index for each battle sprite in a pointer table at $C2CE43. Each entry is 3 bytes, and there are 24 entries. As for overworld NPCs, the GFX index is in the NPC data (like the palette ID), which can be edited with FF6LE. Finally, playable characters get their GFX set with an event command in the same way the palette is assigned, except that the event command $37 is used.
 === B) Color changes in battle ===
-One thing you must keep in mind and be made aware of is battle sprites have color changes during battle. To be more specific, the outer line of characters glows from effects such as Haste, Protect, etc, and their skin tone changes due to Poison, Zombie, etc. These change the colors of the specified number on the palette:
+One thing you must be made aware of and keep in mind is that battle sprites have color changes during battle. To be more specific, the outer line of characters glows from effects such as Haste, Protect, etc, and their skin tone changes due to Poison, Zombie, etc. These change the colors of the specified numbers on the palette:
 {{ff3:ff3us:tutorial:sprites:color-change.png}}
-#1 is what's used for the outline of magical effects around the character, and #2 and #3 are what's used for skin color changes like Poison, Zombie, etc. Please note if you use the skin color for clothing or draw black outlines around your eyes, this will make them change color with the above. Personally, I don't think it's super noticeable, so please don't worry too much.
+#1 is used for the outline of magical effects around the character, and #2 and #3 are used for skin color changes like Poison, Zombie, etc. Please note that if you use the skin color for clothing or draw black outlines around your eyes, this will make them change color with the above. Personally, I don't think it's super noticeable, so please don't worry too much.
-=== C) Color changes in battle ===
+=== C) The four unusable colors ===
-The total number of colors usable for battle sprites isn't 16 actually, but 12. Out of the 16 colors, 4 are masked via the system colors used (finger cursor, damage font color, etc). Since they do not appear in battle, those last 4 colors can be used for NPCs without worring. There is however a [[https://www.ff6hacking.com/forums/thread-2689.html|Expanded palette Hack]] that can make use of those colors and allow you to edit them. The hack does not expand the sprite to have 16 colors but let you choose which of the 12 you want to assign to the sprite.
+The total number of colors usable for battle sprites actually isn't 16, but 12. Out of the 16 colors, 4 are masked by the system colors used in battle (finger cursor, damage font color, etc). Those last 4 colors can be used for NPCs without worrying since they do not appear in battle. There is, however, an [[https://www.ff6hacking.com/forums/thread-2689.html|Expanded palette Hack]] that can make use of those colors and allow you to edit them. The hack does not expand the sprite to have 16 colors, but it lets you choose which of the 12 you want to assign to the sprite.
-However using this hack will make characters on palette 4 and 5 display the last 4 colors save/store/character select screens incorrectly. This is due to the last 4 colors of palette 4 being temporarily overwritten by the color of the status ailment on the menu screen and the last 4 colors of palette 5 being used for the color of the cursor.
+However, using this hack will make the last four colors of a character using palette four or five display incorrectly on the save/store/character select screens.  This is because the last 4 colors of palette 4 are temporarily overwritten by the color of the status ailments on the menu screen, and the last 4 colors of palette 5 are used for the color of the cursor.
 ==== 8. Portraits ====
-Portraits are 40x40 with a palette of 16 colors. Each portrait has its own palette. The easiest way to edit portraits and import custom ones is with FF3SE. Note that the {{ff3:ff3us:tutorial:sprites:terra-import-128.png?linkonly|"trick"}} to have correct import by drawing your palette on the first pixel row also work here. However it is not mandatory but a workaround if you get a bad import.
+Portraits are 40x40, with a palette of 16 colors. Each portrait has its own palette. The easiest way to edit portraits and import custom ones is with FF3SE. Note that the {{ff3:ff3us:tutorial:sprites:terra-import-128.png?linkonly|"trick"}} to correctly import the palette of the portrait by drawing your palette on the first pixel row also works here. It is not mandatory, but it is a useful workaround if you get a bad import.
 {{ff3:ff3us:tutorial:sprites:ff3se-port.png}}
-If you ever edit directly in the ROM with as an example YY-CHR, the tile order is as follow:
+If you ever directly edit the ROM with a program like YY-CHR, the tile order is as follows:
 {{ff3:ff3us:tutorial:sprites:por-tiles-240.png}}
@@ Line 224: / Line 228: @@
 ==== 9. Conclusion ====
-Becoming a good FF6 spriter require to take a lot in consideration. However many started from nothing and became good with time. It's more a matter of practice and knowing the basics, specifications and exceptions before starting for real. This is what I tried to do with this tutorial. I might revise it a bit but I covered most of the content I wanted to cover.
+Becoming a good FF6 spriter requires you to take a lot into consideration. However, many started from nothing and became good with time. It's more a matter of practice and knowing the basics, specifications, and exceptions before starting for real. This is what I tried to do with this tutorial. I might revise it a bit, but I covered most of the content I wanted to cover.
 If you want to read more on the artistic part of Pixel Art, there is a bunch of external tutorial links available on this [[ff3:ff3us:tutorial:external|wiki page]]. Happy spriting!
@@ Line 232: / Line 236: @@
 [[ff3:ff3us:util:ff3se|FF3SE]]\\
 [[ff3:ff3us:util:ff3spriteed|FF3SpriteEd]]\\
-{{ff3:ff3us:util:gfx:yy-chr20120407_en.zip|YY-CHR (C++)}}\\
+[[rh:utilities:yychr|YY-CHR]]