Units & dimensions, part I

Terrain sprites in JA2 use a common scheme whereby floor sprites are 40 pixels wide and wall sprites are 62 pixels tall (though some sprites have extra details that make them extend beyond these boundaries somewhat, thus requiring an offset). Looking closer we can also see that walls are 50 pixels tall from the base of the wall to the top, and that walls are inset slightly such that they always sit on the tile "behind" instead of bridging the gap between tiles.

2D coordinates (units are in pixels and relative to the screen):

Using some trigonometry we can determine the 3D coordinate dimensions of the objects. You would use these values in your 3D modeling application, such as 3DS Max.  Unfortunately, the values are no longer nice, round integers. Instead, values now have a lot of decimal places. For instance, the width of a floor tile is now equal to 40*sin(45°), the wall thickness is 1/5 that amount, and wall height is equal to 50/cos(30°). The wall height to tile width ratio satisfies the equation 5/sqrt(6).

3D coordinates (units are relative to the 3D coordinate system):

To achieve the isometric perspective used by JA2 one must first use an orthographic (i.e. parallel) camera, and then rotate the camera 30 degrees above the horizontal plane, and 45 degrees around the vertical axis. (See this image for a depiction.)

TO DO: "REAL WORLD" UNIT EQUIVALENTS, SUCH AS FEET, METERS, ETC.

Lighting, part II

Since the shadow cast by a wall is the same size as a floor tile, and we know the 3D dimensions of the floor tiles and walls, we can determine the lighting angle with a little more geometry. (Make sure your light source is also parallel, though.) In this case the angle above the horizontal is equal to atan(50/40/cos(30°)/sin(45°)). The angle around the vertical axis is zero since the light is directly north-east.

Outdoor lighting angle (indoor lighting may be slightly different):

Camera, part III

TO DO

The camera should be an orthographic or parallel one; and the rotation angles needed to produce the needed 2:1 pixel ratio are 30 degrees above the horizontal plane and 45 degrees around the vertical axis. See the article Isometric graphics in video games at Wikipedia for more info.

Offsets, part IV

When viewing a sprite in STI Edit you'll notice two important parameters: the x-offset and y-offset. The offsets determine the center (or reference) point of the sprite. The center point is important because it determines where the game places the sprite when rendering the scene. In non-animated sprites the center point tends to remain fixed with respect to the game world. However, animations require that the sprite be translated along some vector in order to produce the illusion of movement. When editing the sprite in STI Edit, however, all you need to do is provide the center and offsets.

TO DO: HOW DOES THE GAME KEEP TRACK OF THE SPEED, POSITION AND DIRECTION OF AN ANIMATION? CAN THEY BE MODIFIED?

TO DO: OFFSETS SEEM TO BE ORIENTED SLIGHTLY DIFFERENTLY IN TERRAIN SPRITES THAN MERC SPRITES. I.E. THEY NO LONGER EVALUATE TO THE CENTER POSITION OF THE SPRITE, BUT RATHER THE UPPER-LEFT CORNER. NEED TO FIGURE THIS OUT FOR SURE.

The coordinates of the center point are not obtained simply by dividing the dimensions of the image by half. Instead, you subtract the offsets from the dimensions in order to get the value. In the close-up view below the center point (marked by an "x") is sixteen pixels from the left side of the image, and 55 pixels from the top - i.e., slightly off-center, below and to the right. This is due to the fact that the merc is in the striding portion of his animation, with his left leg trailing behind him and his body leaning forward.

Palettes, part V

JA2's sprites are 8-bit, paletted images similar to GIF images, whereas JPEG photographs and most likely your desktop are 24 to 32-bits, or "truecolor". This means you only have a "palette" of 255 colors to choose from (plus one more for transparency), instead of the thousands and even millions of possible colors in "truecolor" images. In addition, the palette itself has to be the same across all the frames of an STI animation, and even across multiple animations in a few cases.

One way of editing the palette is by using Photoshop. Open your images as layers, reduce the colors to 256 and save the palette. Then load the Photoshop palette in Sti-Edit and you are done. Alternately, there's an open source tool, pedit, that allows you to import, edit and export Photoshop palettes.

TO DO: NEED TO FIGURE OUT EXACTLY HOW/WHETHER PALETTES NEED TO REMAIN CONSISTENT IN INDIVIDUAL OR SETS OF IMAGES, TILESETS, ETC.

But why are the colors for the merc red, green, blue, pink (actually magenta), etc.? This is because they are "placeholder" colors. JA2 knows by the color red that parts of the image are meant correspond to the person's hair, by the color green that parts of the image are meant to correspond to the person's pants, and so on. The game internally replaces the "placeholder" colors with the "real" colors on-the-fly. And, since the game can replace the "placeholder" with whatever it wants, it means that each merc can have a different skin or hair color without actually requiring a different source sprite. Special cases include the color cyan, which JA2 uses to represent shadows, as well as the colors for boots and guns, which don't change.

You can simulate the process JA2 uses to replace "placeholder" colors using GIMP's "Adjust Hue / Lightness / Saturation" tool, as in the pair of images below.

Shadows, part VI

TO DO

For tips on rendering visible shadows in POV-Ray, see here.

Transparency, part VII

TO DO

JA2 sprites use single bit transparency just like GIF images for the Web. In STI Edit the transparent color appears in the first position (i.e. the top-left) of the palette. To view the effect of the transparent bit has on your sprite in STI Edit, press the T icon in the toolbar.

To convert 8-bit alpha channels to 1-bit dithered transparency, see the instructions using ImageMagick here.

File formats, tools & utilities, part VIII

TO DO

POV-Ray example, part IX

With all this information we should be able to construct entirely new sprites using our favorite 3D modeling application. There happens to already be a small collection of objects for the freeware raytracer POV-Ray that you can use to render game sprites. Those of you familiar with the program may get some use out of it. Go to the POV-Ray Object Collection and search for the "GameSprites" collection. After installing POV-Ray and unzipping the collection, open the file named "GSprites_Combo_demo.pov". This is a demo file included with the collection, and already has all the settings you need to render sprites for JA2. Rendering the scene should result in an image like this:

As you can see from the image, the shadow is exactly the same size as the floor tile, so the lighting angle was chosen correctly, as were the floor and wall dimensions. Check the other "_demo.pov" files to see examples of other objects. When it comes time to rendering the sprites, render the image at 40 by 80 pixels by typing "+W40 +H80" into the input bar above the editing pane. Also delete or comment out the block of code within the union object after the line that says, "delete the following when rendering the actual sprite". If you want to render a 32-bit image with background transparency, also type "+A" into the input bar. For further information refer to the POV-Ray documentation or wiki, or ask at the POV-Ray newsgroups. In particular, there are a lot of INI settings that need to be manually configured in order to set up export paths, formats and so forth, as the installer will not do any of this for you. Unfortunately, POV-Ray is not for the faint-of-heart, though once you learn it you'll find it to be quite powerful.

Unfortunately, there's no way yet of determining such things as the ambient light level, radiosity (doubtful), light source color, light source intensity and material properties (diffusion, specularity, etc.) that the original developers used when creating JA2 simply by examining the game sprites. (See here and here for discussions on doing exactly this.) Further, we do not have access to the developers' original art assets either, sadly.

TO DO: CREATE AN EXAMPLE INTENDED FOR USE AS AN ANIMATION (A MERC WALKING FOR INSTANCE)

See also

• Short tutorial on sprites - Forum thread discussing this article.
• Тайлобилдинг - Russian JA2 spriting tutorial. (Google Translation) 
• Tileset editing guidelines - Editing and creating your own tilesets.
• Improving Original JA2 graphics – Sprites (2) - Description of the differences between sprites in JA2, FOT and Diablo, as well as how JA2 uses palette swapping to create the larger number of colors that we see in the game than in the original and benign-looking source sprites. Also has some recommendations on features that could improve the game.
• Improving Original JA2 graphics – Sprites - The original thread, prior to the one above.
• STI File Structure - Technical description of the STI file format used for JA2's sprites.
• Feature request: 32-bit graphics - Discussion of how 32-bit graphics might improve JA2's visual appearance, as well as how the current 8-bit graphics and palette swapping routines work in comparison.
• Doubling image size - An attempt to double the size of all JA2 sprites.
• Teaser: New Bodytype - One person's attempt at creating a new NPC body type.
• Digging trenches or can a house becomes plane. Isometry studies... - Tutorial on how to fake multi-level terrain in JA2 using clever optical tricks.
• Original Game Assets and copyrights - Discussion of licensing and copyright with repect to JA2's graphics.
• Stupid and unrealistic animations - Another attempt at creating new NPC sprites.
• JA2 Graphics Overhaul & Cinemtaic Cut Scenes - More sprite creation discussion (starts about halfway down the first page).
• How to animate own sprites - Discussion of animated STIs.
• new animations implementation - Some new NPC animations.
• And now for something completely different
• Reverse engineering scene settings from rendered images - Failed discussion of ways to determine scene settings (ambient lighting, materials, etc.) from game images.
• Reverse-engineering scene settings from rendered images - Another discussion on the same topic.
• Reconstructing models from sprites - Failed attempt to reconstruct the 3D geometry from 2D sprites using the Arc 3D web service.
• Isometric graphics in video games - Wikipedia article.