Usually the interface's display is controlled by the player, but when
run_game is executing, it will frequently change the state of an
object in a way that needs to be reflected in the display immediately.
Examples include units leaving or entering a cell, sides losing or
winning, and so forth. The interface must define a set of callbacks
that will be invoked by the kernel.
update_cell_display(side, x, y, rightnow)[introduce area (radius or rect) update routines?]
update_side_display(side, side2, rightnow)
update_unit_display(side, unit, rightnow)
update_unit_acp_display(side, unit, rightnow)
update_action_result_display(side, unit, rslt, rightnow)
update_fire_at_display(side, unit, unit2, m, rightnow)
update_fire_at_display(side, unit, x, y, z, m, rightnow)
update_event_display(side, hevt, rightnow)
update_message_display(side, sender, str, rightnow)
Each of these routines has a flag indicating whether the change may be
buffered or not.
To ensure that buffered data is actually onscreen,
the kernel may call
which the interface must define.
These may or may not be called on reasonable sides, so the
interface should always check first that
exists and has an active display.
[If side has a "remote" display, then interface has to forward??
No, because remote copy of game is synchronized and does own
update_xxx calls more-or-less simultaneously]
Note that this is as much as the kernel interests itself in displays. Map, list, etc drawing and redrawing are under the direct control of the interface code.
Unix-hosted versions must provide
for signal handlers to call.