Sophie: xconq-7.5.0-1.20050612.5mdv2009.1 i586

xconq-7.5.0-1.20050612.5mdv2009.1.i586.rpm

<HTML>
<HEAD>
<!-- This HTML file has been created by texi2html 1.39
     from ./hacking.texi on 12 June 2005 -->

<TITLE>Hacking Xconq - Display Update</TITLE>
</HEAD>
<BODY>
Go to the <A HREF="hacking_1.html">first</A>, <A HREF="hacking_18.html">previous</A>, <A HREF="hacking_20.html">next</A>, <A HREF="hacking_35.html">last</A> section, <A HREF="hacking_toc.html">table of contents</A>.
<HR>


<H2><A NAME="SEC19" HREF="hacking_toc.html#SEC19">Display Update</A></H2>

<P>
Usually the interface's display is controlled by the player, but when
<CODE>run_game</CODE> 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.

</P>

<UL>

<LI>

<CODE>update_cell_display(side, x, y, rightnow)</CODE>

[introduce area (radius or rect) update routines?]

<LI>

<CODE>update_side_display(side, side2, rightnow)</CODE>

<LI>

<CODE>update_unit_display(side, unit, rightnow)</CODE>

<LI>

<CODE>update_unit_acp_display(side, unit, rightnow)</CODE>

<LI>

<CODE>update_turn_display(side, rightnow)</CODE>

<LI>

<CODE>update_action_display(side, rightnow)</CODE>

<LI>

<CODE>update_action_result_display(side, unit, rslt, rightnow)</CODE>

<LI>

<CODE>update_fire_at_display(side, unit, unit2, m, rightnow)</CODE>

<LI>

<CODE>update_fire_at_display(side, unit, x, y, z, m, rightnow)</CODE>

<LI>

<CODE>update_event_display(side, hevt, rightnow)</CODE>

<LI>

<CODE>update_all_progress_displays(str, s)</CODE>

<LI>

<CODE>update_clock_display(side, rightnow)</CODE>

<LI>

<CODE>update_message_display(side, sender, str, rightnow)</CODE>

<LI>

<CODE>update_everything()</CODE>

</UL>

<P>
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 <CODE>flush_display_buffers()</CODE>,
which the interface must define.

</P>

<UL>

<LI>

<CODE>flush_display_buffers()</CODE>

</UL>

<P>
These may or may not be called on reasonable sides, so the
interface should always check first that <CODE>side</CODE> 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]

</P>
<P>
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.

</P>
<P>
Unix-hosted versions must provide <CODE>void close_displays()</CODE>
for signal handlers to call.

</P>

<HR>
Go to the <A HREF="hacking_1.html">first</A>, <A HREF="hacking_18.html">previous</A>, <A HREF="hacking_20.html">next</A>, <A HREF="hacking_35.html">last</A> section, <A HREF="hacking_toc.html">table of contents</A>.
</BODY>
</HTML>