V. Graphics Data

It is easy to create new adventures for the Dragon Bane II engine by modifying data in the Adventure pdb file. Except for the map data which uses a sophisticated mapeditor program, all other data in the adventure pdb is very easy to edit. Therefore, most adventure designers may wish to simply create and distribute their own adventure.pdb data file and re-use the graphics (wall and tile pdbs) that are distributed with Dragon Bane II: Return of Kra'an.

But more adventuresome level designers may wish to go one step farther and customize the graphics in their adventure. If that is the case, you will need to create and distribute your own wall and/or tile pdb data files (see Chapter 2). You may add, remove, or edit any of the graphics that are part of Return of Kra'an to whatever degree you need. You may re-use everything that was in Return of Kra'an graphic files and add your own graphics and wall data to the end of the graphic lists, or you may start from scratch creating whole new sets of tiles and walls in order to create a completely different atmosphere or genre of game.

When creating and editing graphics data for your adventure, keep in mind the following rules:

• All graphics are stored in individual BMP files.
• All graphic files must share a single, common palette (see Chapter 2 for more information on the "PA" palette data type)
• All graphics must be a multiple of 4 pixels wide! (You cannot have any graphic in the entire game that is, for example, 6 pixels wide). If you have a graphic that you want to be 6 pixels wide, you can draw it 6 pixels wide on an canvas that is 8 pixels wide, and make sure the last two columns of pixels are either background color such as white, or mask color which is red.
• The following size restrictions apply to graphic files:
  • Tile graphic maximum size: 80x80
  • Wall graphic maximum size: 160x160
  • Charm graphics must be: 16x16
  • Map tile graphic (small): 4x4
  • Map tile graphic (large): 8x8
• All graphic files must be indexed (with sequential, continuous indicies) in the appropriate tile or brush text files.
• Regardless what palette you choose for your graphic files, the color pure red (255, 0, 0) is reserved for masking.
• All graphic files should be created in triplicate: one for 4, 16 gray, and 256 color versions of the graphic.

A mask is a region in your graphic that is not drawn when the graphic is painted on the screen. It is only important for creating wall graphics and charm graphics (both listed in the brush*.txt index). Those graphics are drawn in the 3D view where it is important to be able to see areas behind your rectangular graphic bitmaps. To indicate that a pixel is a mask in your graphic bitmap file, paint that pixel pure red (255, 0, 0). Those pixels will be skipped when drawing the graphic, so that whatever is behind that object will show through.

An example where masks should be used in your graphics bitmap files are trees which require red masking pixels around the outside of the tree so that you will be able to see the ground and sky and other objects behind the tree.

Try to use masking pixels sparingly because even if only one pixel in a brush is masked, the entire brush will require more memory when your graphic pdb files are stored on the Palm device. For 4 and 16 gray graphic pdb data files, every masked brush requires you to store the graphic as an 8 bit color BMP file (on your desktop computer) instead of a 4 bit gray BMP file. Though the size of your BMP graphic file on your desktop computer is much different from the compiled and compressed version stored in your wall and tile pdbs, all masked graphics (for all color depths) do require more memory in their compiled form on the Palm device.

Tile graphics are those drawn in the top-left corner (top-right if the game is in "lefty" mode) of the Party View screen for characters, buildings, monsters, and objects. All tile graphics must be at most 80x80 pixels, and they should never be masked. Instead, any unused pixels around the border of a graphic should be white (255, 255, 255) so that it's background matches the background of the white party view interface.

You may store and index your tile graphics in any fashion you choose, however you should keep your different color depth tile graphics in separate directories to make them easier to manage. Although tile graphics must be indexed sequentially and continuously, you may break up the tile index file into multiple smaller index files (one for each color depth), so long as the sub-range of tile indicies in each tile index file match the order those tile index files are listed in your pdb.cfg file.

The only restriction to numbering your building tiles is that special building tiles must be first and appear at specific indicies. The following building tile indicies are reserved, and your tile pdb may not replace or move them:

• 0 Shoppe
• 2 Temple
• 3 Treasure opened
• 4 Empty building
• 5 Treasure chest closed
• 6 Party has died (tombstone)
• 9 Temple

Although it is easy to create or edit new tile graphics, as well as change charm icon graphics and floor and ceiling graphics (if you are a good artist), it is much more difficult to create or edit wall graphics. The reason is that walls are complex objects. A wall is not simply a bitmap indexed in some text file. Walls may be viewed from a dozen different angles, and each "view" is constructed from a list of graphic brushes.

Walls are composed of several simple data types, all of which are included in the WALL section of your pdb.cfg files:

• Wall graphics. This is the set of all graphic files (or "brushes") used to constuct all views of your walls.
• Wall list. Each wall has it's own "wall file" which includes all the data needed to draw a wall from a list of graphic brushes. These wall files are all listed and indexed in the walllist.txt file.
• Maptile index. Each wall file includes a piece of data for the index of the small map tile used to represent that wall. In order to draw the zoomed map which uses larger map tile graphics, the maptileindex.txt data file is used to correlate small map tile graphic indicies to large ones.
• Wall files. Each wall file contains a list of data describing how each view of the wall is drawn from a list of graphic brushes (as well as other information about the wall).

Wall graphics can eat up a lot of memory, so when designing new walls, try to keep in mind the following guidelines in order to minimize the memory your walls will require:

• Try to break apart wall views into the appropriate number of graphics.
• If you use too few graphic files to construct a view of a wall, you will end up with large graphic files that take up a lot of memory.
• Try to find symmetry and repetition in your wall graphics so that you can break up your walls into smaller graphics. Remember that you can use vertically and horizontally flipped brushes or even sections from brushes to paint your walls. Take advantage of these features to come up with interesting new patterns that re-use existing wall brushes.
• If you use too many graphic files to construct a view of a wall, you will end up with many tiny graphics that don't take up much memory, but you will have a lot of wall coordinate data that records the position and other information used to draw each piece of the wall. Too much coordinate information can also take up a lot of memory.
• Try to make walls that are modular so that you can re-use pieces of graphics to create many similar walls.
• For views of walls that require masking (such as trees or the side walls of dungeons), try to chop up the image into separate graphic files so that the portions of the wall view that do require a mask are as small as possible. For example, a side view of a brick dungeon wall should have small graphic files for the top and bottom of the side wall with triangular masks, and larger graphic file(s) for the middle portion which does not need a mask.
• Choose a set of 7 "base walls" to occupy wall ID positions 1-7. Base walls are generic, undecorated versions of wall sets that may be referenced each time you want to create a new version of that wall that adds a small decoration. This way, you can create many complex walls out of a simpler set of walls without having to re-specify the memory-consuming coordinates for all the generic attributes of your base walls. For more information on base walls see the wall.txt section.