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.