aboutsummaryrefslogtreecommitdiff
path: root/grid.c (follow)
Commit message (Collapse)AuthorAge
* grid.c: fix size miscalculation in Floret tiling.Simon Tatham2020-04-12
| | | | | | | | | | | | | A Floret grid of height h usually alternates columns of h hexagonal florets with columns of h-1. An exception is when h=1, in which case alternating columns of 1 and 0 florets would leave the grid disconnected. So in that situation all columns have 1 floret in them, and the starting y-coordinate oscillates to make the grid tile sensibly. However, that special case wasn't taken account of when calculating the grid height. As a result the anomalous extra florets in the height-1 tiling fell off the bottom of the puzzle window.
* Use C99 bool within source modules.Simon Tatham2018-11-13
| | | | | | | | | | This is the main bulk of this boolification work, but although it's making the largest actual change, it should also be the least disruptive to anyone interacting with this code base downstream of me, because it doesn't modify any interface between modules: all the inter-module APIs were updated one by one in the previous commits. This just cleans up the code within each individual source file to use bool in place of int where I think that makes things clearer.
* Replace TRUE/FALSE with C99 true/false throughout.Simon Tatham2018-11-13
| | | | | | This commit removes the old #defines of TRUE and FALSE from puzzles.h, and does a mechanical search-and-replace throughout the code to replace them with the C99 standard lowercase spellings.
* New grid type: the trihexagonal tiling, or 'kagome lattice'.Simon Tatham2017-11-18
| | | | | | | | Regular hexagons and equilateral triangles in strict alternation, with two of each interleaved around each vertex. https://en.wikipedia.org/wiki/Trihexagonal_tiling Thanks to Michael Quevillon for the patch.
* Make the code base clean under -Wwrite-strings.Simon Tatham2017-10-01
| | | | | I've also added that warning option and -Werror to the build script, so that I'll find out if I break this property in future.
* New Loopy tiling: 'Great Great Dodecagonal'.Simon Tatham2017-04-24
| | | | | | | | Officially known as the '3-4-6-12 tiling', according to, e.g., https://en.wikipedia.org/wiki/3-4-6-12_tiling . Thanks to Michael Quevillon for contributing this patch (and for choosing a less hard-to-remember name for the tiling :-).
* Sort out abs/fabs confusion.Simon Tatham2015-04-10
| | | | | | | | | | | | | | My Mac has just upgraded itself to include a version of clang which warns if you use abs() on a floating-point value, or fabs() on an integer. Fixed the two occurrences that came up in this build (and which were actual build failures, because of -Werror), one in each direction. I think both were benign. The potentially dangerous one was using abs in place of fabs in grid_find_incentre(), because that could actually lose precision, but I think that function had plenty of precision to spare (grid point separation being of the order of tens of pixels) so nothing should have gone seriously wrong with the old code.
* Fix grid generation crashes at Penrose 3x3 sizes. What seemed to beSimon Tatham2013-05-10
| | | | | | | | | | | | | | | happening was that at the point of calling grid_make_consistent, the grid had no faces or vertices, probably because grid_trim_vigorously had removed them all, causing grid_make_consistent to try to allocate a negative amount of memory and die in snewn. Fixed by detecting this case in new_desc_penrose and retrying until generation is successful. (It wasn't happening 100% of the time, just _most_ of the time.) The same verification step is also used in validate_desc_penrose in case a user manages to manually construct a set of parameters leading to this failure mode. [originally from svn r9840]
* Giant const patch of doom: add a 'const' to every parameter in everySimon Tatham2013-04-13
| | | | | | | | | | | | | | puzzle backend function which ought to have it, and propagate those consts through to per-puzzle subroutines as needed. I've recently had to do that to a few specific parameters which were being misused by particular puzzles (r9657, r9830), which suggests that it's probably a good idea to do the whole lot pre-emptively before the next such problem shows up. [originally from svn r9832] [r9657 == 3b250baa02a7332510685948bf17576c397b8ceb] [r9830 == 0b93de904a98f119b1a95d3a53029f1ed4bfb9b3]
* Revamp the triangular grid generation in Loopy, which I've beenSimon Tatham2013-04-11
| | | | | | | | | | | | | | | | meaning to revisit for a while. The new version generates more nicely symmetric grids (best at even heights, but still improved even at odd heights), and avoids any 'ears' on the grid (triangles at the corners connected to only one other triangle, which tend to be boringly easy places to start solving). I've reused the grid-description-string mechanism invented for the Penrose tilings as a versioning mechanism for the triangular grids, so that old game descriptions should still be valid, and new triangular- grid game descriptions begin with an "0_" prefix to indicate that they are based on the new-style construction. [originally from svn r9824]
* Greg Hewgill points out a code path on which the angle parameter toSimon Tatham2013-04-01
| | | | | | the Penrose grid generation function can fail to be initialised. [originally from svn r9798]
* Apply the rotation in Penrose grid descriptions by rotating in theSimon Tatham2011-05-06
| | | | | | | | | | | | | | | | | | | | 4-vector representation, rather than mucking about with sines and cosines after grid generation. _Should_ make no difference in the generated grids (there's a theoretical risk of an unlucky rounding error just about managing to push some point in or out of bounds, but I think it's vanishingly small), but simplifies the coordinate- flattening procedure, and in particular increases its chance of getting vertical lines actually vertical. (Prior to this change, the game ID 10x10t12:G2554,-31,108_a3b12h0a212a3d102b2a23a2e3b01b0a2c2a0c0 was generating a not-quite-vertical edge at top left, in the Java port but not on Linux; I suspect differences in sin and cos as the cause of the discrepancy. With the rotation done like this, the points' x-coordinates are now computed without reference to their y-coordinates.) [originally from svn r9168]
* Portability fixes, mostly from James for Palm purposes. MostlySimon Tatham2011-05-04
| | | | | | | | additions of missing 'static' and explicit 'void' in parameter lists, plus one or two other things like explicitly casting chars in variadic argument lists to int and using DBL_MAX if HUGE_VAL isn't available. [originally from svn r9166]
* Fix two memory leaks reported by Tiago Dionizio in recent LoopySimon Tatham2011-04-26
| | | | | | development. [originally from svn r9163]
* Forgot to set 'has_incentre' on triangular grids, which don't useSimon Tatham2011-04-25
| | | | | | grid_face_add_new(). Oops. [originally from svn r9161]
* From James Harvey (via a period of collaborative polishing), a patchSimon Tatham2011-04-24
| | | | | | | | | | | | | | | | | | to add two kinds of Penrose tiling to the grid types supported by Loopy. This has involved a certain amount of infrastructure work, because of course the whole point of Penrose tilings is that they don't have to be the same every time: so now grid.c has grown the capacity to describe its grids as strings, and reconstitute them from those string descriptions. Hence a Penrose Loopy game description consists of a string identifying a particular piece of Penrose tiling, followed by the normal Loopy clue encoding. All the existing grid types decline to provide a grid description string, so their Loopy game descriptions have not changed encoding. [originally from svn r9159]
* Oops: initialise that new 'has_incentre' flag to false, otherwise theSimon Tatham2011-04-23
| | | | | | | game will sometimes pick random incentres in place of the carefully computed ones. Ahem. [originally from svn r9158]
* Move most of face_text_pos() into grid.c, leaving in loopy.c only theSimon Tatham2011-04-23
| | | | | | | | | | part that converts from abstract grid coordinates into screen coordinates. This should speed up window-resizing by eliminating pointless reiteration of the complicated part of the algorithm: now when a game_drawstate is renewed, only the conversion into screen coordinates has to be redone. [originally from svn r9157]
* Another patch from Chris Moore implementing two more grid types, bothSimon Tatham2011-02-24
| | | | | | involving dodecagons. [originally from svn r9109]
* Retire the 'middle_face' field in 'struct grid', together with theSimon Tatham2011-02-24
| | | | | | | | | | | overly complicated algorithm that uses it to home in on the grid edge closest to a mouse click. That algorithm is being stressed beyond its limit by the new grid type, and it's unnecessary anyway given that no sensibly sized puzzle grid is going to be big enough to make it prohibitively expensive just to do the trivial approach of iterating over all edges and finding the closest of the eligible ones. [originally from svn r9108]
* Patch from Chris Moore to implement an extra grid type, the 'floret'Simon Tatham2011-02-23
| | | | | | pentagonal tiling. [originally from svn r9107]
* Patch from Chris Moore to improve the generality ofSimon Tatham2011-02-23
| | | | | | | grid_nearest_edge(), by having it search harder for a better dot to move to in the first loop. [originally from svn r9106]
* Since the lack of this has caused portability issues in the past:Simon Tatham2008-09-13
| | | | | | | add "-ansi -pedantic" to the main Unix makefile, and clean up a few minor problems pointed out thereby. [originally from svn r8175]
* Patch from James H to make new-Loopy port more easily.Simon Tatham2008-09-10
| | | | [originally from svn r8174]
* How did I manage to check this in without actually trying to buildSimon Tatham2008-09-07
| | | | | | | | | on Windows at all?! Fix some departures from the C standard, mostly declaring variables after a statement has already been issued in the same block. MSVC is picky about this where gcc is forgiving, and TBH I'd change the latter given the choice. [originally from svn r8166]
* Completely re-engineered version of Loopy, courtesy of LambrosSimon Tatham2008-09-06
Lambrou. Now capable of handling triangular and hexagonal grids as well as square ones, and then a number of semiregular plane tilings and duals of semiregular ones. In fact, most of the solver code supports an _arbitrary_ planar graph (well, provided both the graph and its dual have no self-edges), so it could easily be extended further with only a little more effort. [originally from svn r8162]
generated by cgit v1.1 at 2026-04-25 08:33:19 +0000