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_turn_display(side, rightnow)
update_action_display(side, 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_all_progress_displays(str, s)
update_clock_display(side, rightnow)
update_message_display(side, sender, str, rightnow)
update_everything()
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 flush_display_buffers(),
which the interface must define.
flush_display_buffers()
These may or may not be called on reasonable sides, so the
interface should always check first that side actually
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 void close_displays()
for signal handlers to call.