shithub: puzzles

Download patch

ref: 84d012998fc5c82ff32c85243f8e0f6e9b1e003d
parent: dfb8fa2e928e86f647373814997ee5123740f427
author: Simon Tatham <anakin@pobox.com>
date: Sun Sep 13 10:43:21 EDT 2009 

Error-highlighted trees look nicer with a different-coloured trunk.
Also added a comment worrying about the universality of my error
highlighting mechanism.

[originally from svn r8647]


--- a/tents.c
+++ b/tents.c
@@ -3,7 +3,38 @@
  * some confusing conditions.
  * 
  * TODO:
+ *
+ *  - my technique for highlighting errors in the tent/tree matching
+ *    is not perfect. It currently works by finding the connected
+ *    components of the bipartite adjacency graph between tents and
+ *    trees, and highlighting red all the tents in such a component
+ *    if they outnumber the trees (the red meaning "these tents have
+ *    too few trees between them") and vice versa if the trees
+ *    outnumber the tents (but this time considering BLANKs as
+ *    potential tents as yet unplaced, to avoid highlighting
+ *    'errors' from the word go before the player has actually made
+ *    any mistake). However, something more subtle can go wrong
+ *    within a component: consider, for instance, the setup
  * 
+ *            T
+ *          tTtT
+ *           t
+ * 
+ *    in which there is one connected component containing equal
+ *    numbers of trees and tents, but nonetheless there is no
+ *    perfect matching that can link the two sensibly. This will be
+ *    rejected by the rigorous solution checker, but the error
+ *    highlighter won't currently spot it.
+ * 
+ *    Well, the _matching_ error highlighter won't spot it, anyway.
+ *    In that diagram, there are two pairs of diagonally adjacent
+ *    tents, which will be flagged as erroneous because that's much
+ *    easier. So if I could prove that _all_ such setups require
+ *    diagonally adjacent tents, I could safely ignore this problem.
+ *    If not, however, then a proper treatment will require running
+ *    the maxflow matcher over each component once I've identified
+ *    them.
+ *
  *  - it might be nice to make setter-provided tent/nontent clues
  *    inviolable?
  *     * on the other hand, this would introduce considerable extra
@@ -259,6 +290,7 @@
     COL_TENT,
     COL_ERROR,
     COL_ERRTEXT,
+    COL_ERRTRUNK,
     NCOLOURS
 };
 
@@ -1879,6 +1911,10 @@
     ret[COL_ERRTEXT * 3 + 1] = 1.0F;
     ret[COL_ERRTEXT * 3 + 2] = 1.0F;
 
+    ret[COL_ERRTRUNK * 3 + 0] = 0.6F;
+    ret[COL_ERRTRUNK * 3 + 1] = 0.0F;
+    ret[COL_ERRTRUNK * 3 + 2] = 0.0F;
+
     *ncolours = NCOLOURS;
     return ret;
 }
@@ -2140,7 +2176,7 @@
 	(printing ? draw_rect_outline : draw_rect)
 	(dr, cx-TILESIZE/15, ty+TILESIZE*3/10,
 	 2*(TILESIZE/15)+1, (TILESIZE*9/10 - TILESIZE*3/10),
-	 (err & (1<<ERR_OVERCOMMITTED) ? COL_ERROR : COL_TREETRUNK));
+	 (err & (1<<ERR_OVERCOMMITTED) ? COL_ERRTRUNK : COL_TREETRUNK));
 
 	for (i = 0; i < (printing ? 2 : 1); i++) {
 	    int col = (i == 1 ? COL_BACKGROUND :