simon-git: puzzles (main): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Sun Jun 18 14:39:29 BST 2023


TL;DR:
  68a1e84 spectre.c: expose a couple more internal functions.
  14db5e0 spectre_adjacent: optionally report dst_edge.
  da014d2 spectre-test: support raster-mode tiling generation.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2023-06-18 14:39:29

commit 68a1e8413c500f62f81c5a283de47bf404346edc
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=68a1e8413c500f62f81c5a283de47bf404346edc;hp=86466959e8dc127513c1dc5c702492c8107c4b20
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Jun 18 09:18:58 2023 +0100

    spectre.c: expose a couple more internal functions.
    
    spectre-test will want to use these for an additional generation mode.

 spectre-internal.h | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 spectre.c          | 18 +++++++-----------
 2 files changed, 59 insertions(+), 13 deletions(-)

commit 14db5e0145e0942e5cf851d696aebd2347418087
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=14db5e0145e0942e5cf851d696aebd2347418087;hp=68a1e8413c500f62f81c5a283de47bf404346edc
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Jun 18 13:33:28 2023 +0100

    spectre_adjacent: optionally report dst_edge.
    
    Previously, you'd ask this function 'What lies on the other side of
    edge #i of this Spectre tile?' and it would tell you the identity of
    another Spectre. Now it will also tell you which _edge_ of that
    Spectre adjoins the specified edge of the input one. This will be used
    in the extra spectre-test mode I'm about to add.

 spectre-internal.h | 2 +-
 spectre.c          | 6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

commit da014d23dad4bcff0215d9ba7758652c85c06a20
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=da014d23dad4bcff0215d9ba7758652c85c06a20;hp=14db5e0145e0942e5cf851d696aebd2347418087
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Jun 18 14:11:52 2023 +0100

    spectre-test: support raster-mode tiling generation.
    
    This is the most efficient way to apply the combinatorial coordinate
    system. As described in my original article (and mentioned again in
    the followup one), you can walk along a horizontal or vertical line of
    the tiling, identifying which edge of each tile the line will leave it
    by, and computing the location and coordinates of the next tile beyond
    that edge, so that you visit every tile intersected by the edge.
    
    By doing one iteration, say vertically up the left of your target
    area, and using the tiles you find as starting points for a series of
    perpendicular sub-iterations spaced closely enough not to miss any
    tiles, you can arrange to visit every tile intersecting your target
    region, without having ever had to store a large BFS queue of tiles
    left to visit. You only have to keep a small bounded number of
    coordinate variables for the whole run, so you can generate a very
    large patch of tiling with minimal memory and CPU time.
    
    You can even arrange not to emit any duplicates, without having to
    actually store the tiles you've already visited, by checking whether
    the y-coordinate of the previous horizontal iteration will have
    visited the same tile already.
    
    For Spectres, an extra wrinkle (almost literally) is that they're not
    convex, so a horizontal line can visit the same one twice, with
    another tile in between. So another part of de-duplication is noticing
    _that_: is the edge through which we've just entered this tile the
    first one we would have seen while traversing our line? If not, then
    trust that it's been emitted already.
    
    As a proof of concept (since I claimed it would work in my writeup
    article), and in case anyone wants larger tilings than actual Loopy
    will conveniently give you, I've implemented that algorithm in
    spectre-test.
    
    However, the actual grid generation for Loopy still uses the more
    memory-intensive breadth-first search: because that's what I
    implemented first (it's more likely to detect its own errors); because
    if I changed it now it would invalidate game descriptions (from all of
    two days' worth of live play, but even so); and because the linear
    space requirement isn't an important cost for Loopy, which is actually
    going to _store_ the whole grid after it's generated, so it needed
    linear space _anyway_.

 auxiliary/spectre-test.c | 299 +++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 277 insertions(+), 22 deletions(-)



More information about the tartarus-commits mailing list