TODO/wishlist file for IPBT
===========================

Things I'd definitely like to see done:

 - [RESUME] Make it easy to resume playback of the same set of
   ttyrecs at another time, by means of printing out on exit the
   actual command line which would load the same files and resume
   the playback at the same place. (Perhaps command-line options to
   restore the same speed settings would improve functionality in
   this area and be generally useful too. Also we should output
   appropriate width and height options. And probably Bourne-shell-
   quote the filenames in the output command line. And supply enough
   -N/-T options. Generally a pain, in fact, but useful.)

 - [HELP] In the player, the user should be able to press `h' or `?'
   (probably both) for a help screen. Currently the available
   keypresses are only documented in README.

 - [OUTSIZE] Make intelligent use of the size of the output screen.
   If you play an 80x24 animation on an 80x25 screen, for example,
   there would be space to put a permanent OSD at the bottom rather
   than being dependent on the current intrusive OSD. Conversely, if
   you display a large animation on a small screen then it might be
   nice to permit the user to scroll around the display area. While
   we're here, we could usefully detect screen resizes in mid-replay
   and do something useful with them (but see [UXPORT] - this has to
   be done differently on vanilla curses which doesn't support
   ncurses's incredibly useful KEY_RESIZE).

Things I haven't quite decided whether I want yet:

 - [GAP] Currently, if you specify more than one ttyrec file on the
   input command line, ttyrec assumes a one-second delay between the
   final frame of one and the initial frame of the next. This delay
   could easily be made configurable using a command-line option.
   I'm not sure whether this is actually worth bothering with.

 - [MMAP] It might be an interesting idea to optionally be able to
   store the internal movie data in a disk file, probably just by
   using mmap(2) instead of malloc(3). This would be convenient if
   you planned to watch the same movie in multiple sittings: you'd
   only have to go through IPBT's lengthy setup phase once. Depends
   on [CLOPT].

 - [NHTURN] When reading a NetHack replay in particular, the program
   could usefully spot the turn counter on the status line and track
   it throughout the replay, which would permit the user to jump
   straight to a particular turn number if you knew the turn number
   where something interesting had happened. However, I'm uncertain
   as to whether this is a sensible feature to add because it's
   rather NH-specific: it would set a precedent that adding specific
   support for everyone's favourite application was a sensible thing
   to do. Perhaps better to leave it as it currently is: you can
   jump to an arbitrary ttyrec frame by its frame number, and if you
   need to track down a particular NetHack turn number you can
   binary-search the available frames. An approach feasible with
   existing features is just to search for `T:12345', although this
   takes linear time rather than the log time one could achieve by
   making use of the known monotonicity.

 - [SAVEFILE] Save the movie data to a file once processed and
   sorted. If one is planning to watch a very long replay in many
   stages, this would allow the tedious preparation stage to be done
   only once. Ties in to [RESUME], if implemented: the resume
   command line would want to specify the output movie file rather
   than the inputs. Downside is that there would be confusing
   portability concerns about the movie file itself; carefully
   making sure of its cross-platform portability would slow down
   lookups in it, but conversely I predict that if I _don't_ make it
   a well-defined portable format then Murphy's Law says people will
   probably try to use it as an interchange format and complain when
   it doesn't work...
    + well, a simple answer to this is to start the file off with a
      dummy movie record containing known data, make sure we can
      load it in correctly, and give a reasonably informative error
      message if not.

Longer-range ideas which would involve a lot of work:

 - [ABSTRACTION] Abstract the core technology away from the Curses
   player UI, to permit non-Curses output drivers. I envisage a
   source module which exports functions along the lines of
   read_ttyrec_file(), sort_movie_array() and the current
   int_for_frame(). Possibly also move some of the player logic into
   another output-independent source module, so that things like the
   logarithmic time compression and the rather carefully tuned
   behaviour of the `b' key don't have to be re-implemented between
   platforms.

 - [WINPORT] A Windows GUI player, displaying in a PuTTY-like
   terminal window, would be nice. The terminal output code might be
   able to steal a lot from PuTTY again (in particular, it would be
   nice to take _enough_ code from PuTTY that copy-and-pasting from
   a replay window was still supported). This would involve
   considerable GUI work: Windows users would probably expect
   friendly drop-down File/Edit menus and a GUI toolbar showing the
   contents of the OSD, and would be a bit miffed to find an exact
   Windows clone of the current Curses keyboard-and-command-line
   interface. Depends on [ABSTRACTION].

 - [SEARCHREFINEMENTS] It might be useful to remember at what _point
   on the screen_ the search text was found in previous frames, so
   that we can avoid finding it again in that precise place. In
   other words, we'd now be searching for frames in which the search
   text has _just appeared_ rather than simply being present.
   Helpful if, for example, you search for something which appears
   in a Nethack player's inventory, because otherwise the search
   will stop at _every_ frame during a lengthy inventory
   manipulation. However, this is significantly more complex than
   the current simple searching, so I haven't done it yet.

 - [BGLOAD] Have a mode in which the player starts up instantly, and
   the rest of the file(s) are read in the background while
   processing keypresses. There would still be an unavoidable delay
   if the user wanted to go straight to the end of the file or jump
   to a frame that wasn't loaded yet, but it might be an improvement
   on the current non-negotiable delay. On the other hand, the
   complexity of background-loading the file might be prohibitive:
   it might require multithreading to do properly, for example.
