Damaniel's Pixel By Number
==========================

This is a paint by number game. Think something like the mobile game Cross
Stitch World, or something like actual diamond painting.

While I'm not ready to call the game 'complete', I believe that all of the
planned functionality is in.

See the PDF manual for more details about the interface, controls and other
features of the game.

Requirements
------------

   A 386 or higher (it runs in protected mode)
   Some amount of RAM. 4MB is probably enough in all cases. Smaller images will
     work with 2.
   A VGA card. It uses Mode 13 (320x200, 256 colors), supported by all VGAs.
   A copy of CWSDPMI.EXE, either in the program directory or on your PATH.

Additional tools
----------------

There are some tools in the 'tools' directory. You can build the C programs them
by running make tools from the root of the main directory. These tools are:

   convert: The tool that creates picture files from PCX files. Run convert.exe
            for usage instructions
   expand: takes a PCX saved in 16 color mode and converts it to a 256 color
           version. This is important since it allows the creation of picture
           files with fewer than 16 colors while maintaining compatibility with
           Allegro.
   installer: creates an installer for the game, meant for copying files from a
              floppy disk to (presumably) a hard drive

The python tools are some batch converters that I'm using to make larger
collections. They are:

   batch_convert.py: takes a directory of image files and creates a set of
                     DamPBN picture files in a separate output directory.
                     Supported image file formats are JPG, PNG and PCX.
                     This converter will also adjust the image size and color
                     palette if needed, so any images can be used without
                     preprocessing.
   image_process.py: takes 2 directories of identical files - one with original
                     names, one with numbered names, and makes a metadata file
                     for batch_convert.py
   image_split.py: takes a pile of images and divides them into groups of 50,
                   putting each group into sequentially numbered directories

An additional python tool is present:

   generate_manifest.py: creates a manifest for the installer. Scans a
                         directory tree and generates a file that tells
                         the installer what directories to make and what files
                         to copy

Build requirements
------------------

This program can be built in one of two ways:

   A modern version of DJGPP and Allegro (9.3.0 and 4.2.2 respectively).
   My 'old' toolchain (gcc 2.95.2 and Allegro 3.12)

The modern version is the default. Running make will generate this version of
the program. If you want to build the old version, running
'make -f Makefile.295' will do that instead.

Also note that the 2.9.x toolchain isn't widely available - I have a bespoke
setup on my PC for it. The main reason to use it is compile speed - it builds
much faster on older hardware and generates smaller executables. The newer
version also loads a fair bit slower on older hardware, though seems to run more
or less at the same speed. For playing around on DOSBox, the default build is
fine - the 'old' build will probably just be offered as binary packages for now.

Note that the upx call in make prod in the modern DJGPP build will fail on
DOSbox due to the compiler setting the executable read-only. For now, until I
figure out what to do about it, just run upx on it manually if desired.

Deployment
----------

The steps required to deploy a copy of the game is:

   Build the code
   Build the tools
   (If needed) Build the installer
   Copy the required distribution files to a target directory and compress
      them as needed
   Run the manifest generator in the target directory
   Take the resulting directory and use a tool like WinImage to make a floppy
      image file from it

One issue is that the first 4 steps need to be done from a DOS environment,
while the last 2 need to be done in an environment with a copy of Python and a
copy of WinImage (or some other tool that can generate floppy images from a
directory tree). As a result, my current workflow is to:

   Run 'make' or 'make -f Makefile.295 prod' from the DamPBN directory
   Run 'make tools' from the DamPBN\tools directory
   Run 'build' from the DamPBN\tools\install directory
   Copy the relevant files (binaries, cwsdpmi.exe, resources, pic files) to a
      DIST directory
   Run UPX on all the binaries that need it (dampbn.exe, install.exe,
      covert.exe, expand.exe) in DIST
   Run the manifest generator from DIST
   Use WinImage to make a disk from the contents of DIST

Not very convenient (and it certainly could be more automatable with some work),
but I make releases so infrequently that I don't mind doing a couple manual
steps once or twice a year.

What's done
-----------

   Logo screen, title screen
   Save / Load
   Mouse support
   Funcional timer
   'Mark' (highlight) function
   3 different pixel styles
   Overview 'map' showing overall progress
   High level overview on the main game screen
   Load picture menu
   Help screen
   Replay of draw progress on screen when picture is complete
   Auto save on exit
   The ability to watch completed replays from the image select screen
   An installer (and a floppy image that uses it)
   An experimental MIDI player
   Option screen (continue last, start/continue another), with configuration
   Periodic auto-save

Note that the MIDI player itself isn't experimental (it's just using Allegro
code), the behavior is. It currently plays through a series of MIDI files that
are placed into RES/MUSIC, as long as the player is working on an image. It
doesn't play on the title screen, loading screen (when coming from the title
screen), or the image complete screen, since if I were to provide MIDI files,
there would be separate ones for each of those. I'm sure I'll come up with
something better and I'm planning to add keys to play the previous/next song
in the list.

What's left to do?
------------------

Right now, the only other feature I might add is some sound effects, but I
don't think that would add very much. Functionally, I think the game is
complete.

Outside of the game, I need to finish up the manual, which is mainly adding the
option section, make the terminology more consistent ('Image' instead of
'Picture'), and check for typos/incorrect stuff.

Current bugs to fix
-------------------

   None that I know of, but I'm sure there's plenty.

Additional notes
----------------

Currently, images can be up to 320x200 pixels in size, with up to 64 colors.
There are two Image versions:

   version 1 only supports square/rectangular images (i.e. every square in a
      X x Y region needs to be a color)
   version 2 allows non-square/irregular images. The tools that create these
      use a transparency mask to determine which squares will need to be
      colored and which won't.
   Version 2 is backward and forward compatible. The version 1 reader will skip
      version 2 data, and the version 2 reader treats the version 1 files like
      earlier versions of the game.