simon-git: puzzles (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  6da8dc9 Map: stop storing pixel coordinates in game_ui.
  69773d8 Solo: remove some overzealous assertions in the solver.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2017-10-28 11:59:08

commit 6da8dc91a2c1ecd5cc7e02bc63d1404bf80382f9
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=6da8dc91a2c1ecd5cc7e02bc63d1404bf80382f9;hp=efcc00ffefa34b2c4048e560099814c19a064ba5
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 28 08:55:33 2017 +0100

    Map: stop storing pixel coordinates in game_ui.
    
    The fields (ui->dragx,ui->dragy) stored the pixel coordinates of the
    visible cursor (if any), no matter whether that cursor was being
    displayed in response to a mouse dragging action or arrow-key
    activity. But this meant that resizing the window while the keyboard
    cursor was visible would cause the cursor to be drawn in totally the
    wrong place in the newly resized window: you get a new drawstate with
    a fresh blitter (so at least no part of the old-size window is
    accidentally 'restored' on to the new-size one), but the ui fields
    saying where _next_ to draw the cursor would still have bogus values
    left over from the previous window size.
    
    To fix this, I've arranged that we simply don't use ui->dragx and
    ui->dragy any more in keyboard cursor mode: instead, we leave it to
    game_redraw to spot that the keyboard cursor is visible and compute
    its pixel coordinates for display.
    
    A knock-on effect is that when we need to know which region is under
    the cursor during interpret_move, we can't use the previous strategy
    of just calling region_from_coords(ui->dragx, ui->dragy) regardless of
    which kind of cursor is active. So I've split that function up into an
    inner section taking a tile and a displacement from the tile's centre
    and an outer part which derives those from real pixel coordinates in
    the case where the cursor is originating from a mouse drag; then
    there's a new alternative outer part which derives the same (tile,
    displacement) pair purely from the game_ui keyboard cursor data
    without having to explicitly translate into pixels and back in the
    middle. Probably a less fragile strategy anyway.

 map.c | 67 +++++++++++++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 45 insertions(+), 22 deletions(-)

commit 69773d855b517ea356c3c02add97893201de2066
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=69773d855b517ea356c3c02add97893201de2066;hp=6da8dc91a2c1ecd5cc7e02bc63d1404bf80382f9
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 28 11:36:47 2017 +0100

    Solo: remove some overzealous assertions in the solver.
    
    There were a couple of places where we enforced by assertion that our
    solver state had not become inconsistent, on the assumption that some
    previous piece of solver would have detected that the puzzle was
    impossible before getting to that place in the code.
    
    But in fact the combination of Killer and Unreasonable modes falsified
    at least two of those assumptions: 'solo --test-solve --generate 100
    3x3kdu#12345' triggered an assertion failure in solver_set, and with
    that one fixed, the same command triggered a second failure in
    solver_killer_sums.
    
    In both cases, the fix is simply to return -1 for 'puzzle is
    inconsistent', which will cause the Unreasonable recursive solver to
    abandon that branch of its search tree, backtrack, and try a different
    guess at some previous square.
    
    Thanks to Anders Höglund for the report.

 solo.c | 30 ++++++++++++++++++++++++------
 1 file changed, 24 insertions(+), 6 deletions(-)