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.
- [MAN] Man page.
- [UXPORT] Unix portability work. There ought to be an autoconf
framework, and any dependencies on ncurses rather than vanilla
curses (use_default_colors() in particular) ought to be hidden
behind autoconf-derived ifdefs.
- [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
- [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
- [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.