Demonstrates combining time-varying data (discrete datatimes) with time-varying warp (continuous extrapolation).

Add -a (anyway) option: include stars even if there's no corresponding radial velocity record.

Check the right thing -- ac_cv_header_jpeglib_h -- to see whether we've found the JPEG header and need to find corresponding library.

For MacOS (Lion), use -framework Cocoa rather than -framework Carbon, following fltk-1.3's lead.  No, I don't understand why.

Update derived files.

so it doesn't collide with VERSION file.

Try to make jpeglib.h work right under Windows/MinGW.  Need to declare our own "boolean" type for some stupid reason.

Default jpeg quality = 97.

Flip Y when encoding PNGs.
Always free the snapshot buffer.

Use hack-y MINGW32 test to see which version of GLEW library to use --
"-lGLEW" on most systems, "-lglew32.dll" (libglew32.dll.a) on MinGW.

   - four digits by default
   - use .png suffix if libpng available, or if unix (assumes "convert" available)
   - use .ppm suffix if WIN32 and no libpng

for comparison with -c 'early commands', before window setup.

Add -tilt option to subcam command.

"vec"/"vecscale" control commands, and "vecvar" data command.

"vec off", "vec on", or "vec arrow".  With "arrow",
draws an arrowhead on each vector, with 3-D size equal to
the vector's length times the 'arrowscale'.  The arrowhead always
lies in the screen plane, so its size gives a cue to the vector's
true 3-D length (e.g. when the vector is viewed nearly end-on,
even a small arrowhead can look longer than the vector does).
This also means that arrowheads flip orientation when a vector
passes through being seen nearly end-on.

Arrowhead size is set by a new second parameter to "vecscale".
Default is 0.25, meaning that arrowheads are a quarter the main vector's length.

should we draw arrows too?  How large should arrowheads be (in 3D)
as a fraction of vector length?