diff options
| author | Simon Tatham <anakin@pobox.com> | 2009-09-13 14:43:21 +0000 |
|---|---|---|
| committer | Simon Tatham <anakin@pobox.com> | 2009-09-13 14:43:21 +0000 |
| commit | 84d012998fc5c82ff32c85243f8e0f6e9b1e003d (patch) | |
| tree | bae98921b28ce6ad3ce6c05440b4548595611931 | |
| parent | dfb8fa2e928e86f647373814997ee5123740f427 (diff) | |
| download | puzzles-84d012998fc5c82ff32c85243f8e0f6e9b1e003d.zip puzzles-84d012998fc5c82ff32c85243f8e0f6e9b1e003d.tar.gz puzzles-84d012998fc5c82ff32c85243f8e0f6e9b1e003d.tar.bz2 puzzles-84d012998fc5c82ff32c85243f8e0f6e9b1e003d.tar.xz | |
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]
| -rw-r--r-- | tents.c | 38 |
1 files changed, 37 insertions, 1 deletions
@@ -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 @@ enum { COL_TENT, COL_ERROR, COL_ERRTEXT, + COL_ERRTRUNK, NCOLOURS }; @@ -1879,6 +1911,10 @@ static float *game_colours(frontend *fe, int *ncolours) 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 @@ static void draw_tile(drawing *dr, game_drawstate *ds, (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 : |