aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Cleanups from James H: a few missing statics, a precautionary castSimon Tatham2005-08-03
| | | | | | | | | or two, a debugging fix, a couple of explicit initialisations of variables that were previously read uninitialised, and a fix for a whopping great big memory leak in Slant owing to me having completely forgotten to write free_game(). [originally from svn r6159]
* Slant uses the same generation strategy as Solo, despite not havingSimon Tatham2005-08-03
| | | | | | | | | the property which devel.but claimed to be the reason why that strategy works. A bit of thought revealed what the _real_ reason is why this strategy works in some puzzles and not others, so I've rewritten the paragraph to be more accurate. [originally from svn r6158]
* Bah! There's _always_ one. Display glitch corrected.Simon Tatham2005-08-02
| | | | [originally from svn r6156]
* New puzzle: `Slant', picked from the Japanese-language section ofSimon Tatham2005-08-02
| | | | | | | | | | | nikoli.co.jp (which has quite a few puzzles that they don't seem to have bothered to translate into English). Minor structural change: the disjoint set forest code used in the Net solver has come in handy again, so I've moved it out into its own module dsf.c. [originally from svn r6155]
* Various cleanups and clarifications to devel.but; some from RichardSimon Tatham2005-08-01
| | | | | | | | | B and some from me. Also an additional utility function `random_copy' from Richard B, which he says is useful in a new puzzle he's working on and which seems likely to come in handy again at some point. [originally from svn r6153]
* New end-game approach to Black Box. Instead of revealing the ballSimon Tatham2005-07-31
| | | | | | | | | | | positions immediately when you make an error, the game now reveals as little information as is necessary to prove you wrong (including none - if an existing laser path you know about is inconsistent with your guesses, the game will just point it out and tell you nothing new!) and you can try again. Errors are counted in much the same way as deaths in Mines. [originally from svn r6152]
* missing `i' in `\e'Jacob Nevins2005-07-29
| | | | [originally from svn r6151]
* One more fix from Ben H. Also switched round the arena colourSimon Tatham2005-07-29
| | | | | | | | | | | selection in the redraw function, so that locked squares are no longer displayed once the game is at an end. (It looked untidy and disorienting for lighter-coloured locked squares to suddenly become darker when the box was opened. You can still flip back and forth to your previous game state using undo/redo if you want to compare the results against your lock pattern.) [originally from svn r6150]
* Various fixes and cleanups suggested by Ben Hutchings:Simon Tatham2005-07-29
| | | | | | | | | | | | | | | | | - clarified wording of messages in validate_params(), including in particular a correction from `< 255' to `<= 255' - fixed random_upto() in game generation which caused the maximum number of balls never to be used when there was uncertainty - fixed widespread miscalculation of rectangular-array indices (multiplication by h instead of w, which would have broken non-square grids rather profoundly) - corrected an ANSI namespace violation - removed real functionality from the inside of assert() statements, so that the game should still work when compiled -DNDEBUG - couple of unnecessary linear-time loops removed. [originally from svn r6149]
* Ben Hutchings reports that gcc 4 gives an optimiser warning becauseSimon Tatham2005-07-29
| | | | | | | | it can't tell that one branch of a particular switch is always taken. Adding a default clause with an automatic assertion failure apparently fixes it. [originally from svn r6148]
* Patches from Ben Hutchings to fix failures of sscanf error checking.Simon Tatham2005-07-29
| | | | [originally from svn r6147]
* Tweak a paragraph after discussion with Simon.Jacob Nevins2005-07-29
| | | | [originally from svn r6144]
* Shiny new developer documentation to replace the old sketchy HACKINGSimon Tatham2005-07-28
| | | | | | guide. [originally from svn r6142]
* The very core of cross() is capable of suffering integer overflow onSimon Tatham2005-07-24
| | | | | | | | | | | large puzzles. Resort to hand-hacked 64-bit arithmetic for doing dot products; everything else remains in `long' for the moment. (Ideally I'd auto-detect the presence of `long long' and use it in place of my cheap plastic imitation where possible, but since I currently don't have a configure mechanism that'll have to wait.) [originally from svn r6137]
* Another diagnostic mode for Untangle: if compiled withSimon Tatham2005-07-24
| | | | | | | | | `-DSHOW_CROSSINGS', it will show each edge in red if it is crossed by anything, and in black otherwise. Distracting and not particularly useful during play, but occasionally handy for debugging cross(). [originally from svn r6136]
* (GTK only so far) Allow the argument passed to a game binary to beSimon Tatham2005-07-24
| | | | | | | | either a game ID or a save file name. (The former takes priority, because you can usually find a synonym for the latter, such as by prepending `./' or `$PWD/'.) [originally from svn r6135]
* Solve animation (currently only in Untangle) was failing to setSimon Tatham2005-07-22
| | | | | | | | me->anim_pos to zero, meaning that if it happened immediately after a completion flash then anim_pos would start off half way through its run. [originally from svn r6127]
* The `Solve' operation now rotates and/or reflects the solution gridSimon Tatham2005-07-22
| | | | | | | | | | | to bring it as close as possible to the current game state. This means that if you request `Solve' after solving a puzzle yourself, with the intention of finding out how similar your solution is to the program's, then you will mostly see the differences in _shape_ rather than those being masked by the fact that yours happened to be the other way up. [originally from svn r6126]
* James H profiled the new Same Game grid generator and discovered itSimon Tatham2005-07-22
| | | | | | | | | | | | | was spending 60% of its time in shuffle(). The purpose of the shuffle() call was to go through a largish array in random order until we found an element that worked, so there's no actual need to shuffle the whole array every time and I only did it out of laziness. So I now pick a random element each time I go round the loop, meaning I save a lot of shuffling effort whenever the loop terminates early (which is often). I get about a factor of two speed improvement from this small change. [originally from svn r6125]
* Until now, Same Game has been the only puzzle in this collectionSimon Tatham2005-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | which is unable to guarantee that every grid it generates can be solved. So I'm eliminating that exception: this checkin contains a more sophisticated grid generator which does guarantee solubility. It's a bit slow (most noticeably on the 15x10c3 preset), and the quality of the generated grids is slightly weird (a tendency toward small regions rather than large sweeping areas of contiguous colour); however, I'm willing to see the latter as a feature for now, since making the game more challenging while simultaneously guaranteeing it to be possible sounds like an all-round win to me. From now on I'm raising my standards for contributions to this collection. I made this fix to Same Game because I heard a user _automatically assume_ that any puzzle in my collection would not be so uncouth as to generate an impossible grid; as of this checkin that's actually true, and I intend to maintain that standard of quality henceforth. (Guaranteeing a _unique_ solution is more of an optional extra, since there are many games for which it isn't a meaningful concept or isn't particularly desirable. Which is not to say that _some_ games wouldn't be of unacceptably low quality if they failed to guarantee uniqueness; it depends on the game.) [originally from svn r6124]
* I've been meaning to do this for ages: all the Makefiles now giveSimon Tatham2005-07-21
| | | | | | | | | $(XFLAGS) _after_ $(CFLAGS) on the compiler command lines, meaning that you can provide options in XFLAGS on the makefile which will override the ones in CFLAGS. For example, `make XFLAGS=-O0' to make debugging easier. [originally from svn r6123]
* Sync with websiteJacob Nevins2005-07-20
| | | | [originally from svn r6122]
* The Untangle completion flash was weedy and anaemic; beef it up aSimon Tatham2005-07-20
| | | | | | | | | bit. In particular, it now flashes between _two_ specially picked colours (white and mid-grey), meaning that it should be visible even if your default background colour is white; and it also flashes twice rather than once. [originally from svn r6121]
* Some attempt to explain Dominosa for those unfamiliar with dominos. (Not sureJacob Nevins2005-07-19
| | | | | | I've succeeded.) [originally from svn r6120]
* Another fix from Chris: Guess's allow-blanks mode wasn't allowingSimon Tatham2005-07-18
| | | | | | blanks... [originally from svn r6118]
* Fix to Chris's patch in r6106 (also from Chris).Simon Tatham2005-07-18
| | | | | [originally from svn r6117] [r6106 == a31934f233581da07153af6b4ee717f1e63387dd]
* Switch Untangle to using `long' rather than `int' in its internalSimon Tatham2005-07-17
| | | | | | | rationals, for the sake of 16-bit-int platforms such as Palm. Thanks to James H. [originally from svn r6114]
* Quite a few instances of the Cardinal Error of Ctype were turned upSimon Tatham2005-07-17
| | | | | | by a grep I just did. Oops. [originally from svn r6113]
* Two tiny cleanup patches from James H.Simon Tatham2005-07-17
| | | | [originally from svn r6111]
* Get rid of the malloc in shuffle(), by defining a subfunctionSimon Tatham2005-07-17
| | | | | | | memswap() which declares a fixed-size buffer on the stack and uses it multiple times if necessary. [originally from svn r6107]
* Patch from Chris Emerson: rather than dynamically callingSimon Tatham2005-07-17
| | | | | | | get_correct() at (among other things) every redraw, we call it once at the creation of a new game_state to save CPU. [originally from svn r6106]
* Black Box: fix "reveal" button location, explain what's meant by theJacob Nevins2005-07-17
| | | | | | `firing range' [originally from svn r6105]
* Use \q{} and \by in Black Box docs.Jacob Nevins2005-07-17
| | | | [originally from svn r6104]
* I keep forgetting to do things when adding a new puzzle, so here's aSimon Tatham2005-07-17
| | | | | | checklist. [originally from svn r6103]
* Bah, there's always one: failed to `svn add' blackbox.c itself!Simon Tatham2005-07-17
| | | | [originally from svn r6101]
* Another game from James H: `Black Box'.Simon Tatham2005-07-17
| | | | [originally from svn r6100]
* Cleanups and memory leak fixes from James H.Simon Tatham2005-07-16
| | | | [originally from svn r6099]
* Sanity-checking patch from Phil Bordelon: since Solo can't cope withSimon Tatham2005-07-16
| | | | | | | | | | more than 36 distinct symbols (it runs out of alphanumerics), check this in validate_params. I hate to do this, since I like puzzle sizes to at least be open-ended in _principle_, but in this case there's a fundamental UI limitation which won't be fixed by getting a faster CPU. [originally from svn r6098]
* New puzzle: `Untangle', cloned (with the addition of random gridSimon Tatham2005-07-16
| | | | | | | | | | | | | | | generation) from a simple but rather fun Flash game I saw this morning. Small infrastructure change for this puzzle: while most game backends find the midend's assumption that Solve moves are never animated to be a convenience absolving them of having to handle the special case themselves, this one actually needs Solve to be animated. Rather than break that convenience for the other puzzles, I've introduced a flag bit (which I've shoved in mouse_priorities for the moment, shamefully without changing its name). [originally from svn r6097]
* Improve speed of grid generation: I've found something simple I canSimon Tatham2005-07-15
| | | | | | | | do during construction which massively increases (by over a factor of four with default parameters) the probability that any given randomly generated grid will be uniquely solvable. [originally from svn r6096]
* Add Dominosa printout support.Jacob Nevins2005-07-14
| | | | [originally from svn r6094]
* Cleanups to Solo:Simon Tatham2005-07-14
| | | | | | | | | | - use the new `shuffle' utility function in a couple of places - remove the random_state parameter from solver(). It was there because I initially wanted to use the same solver for grid generation, but since I had to abandon that plan the solver now doesn't have any need for randomness at all. [originally from svn r6093]
* New puzzle: Dominosa.Simon Tatham2005-07-14
| | | | [originally from svn r6091]
* Introduce a `shuffle' utility function.Simon Tatham2005-07-14
| | | | [originally from svn r6090]
* game_timing_state() now has access to the game_ui. This means thatSimon Tatham2005-07-10
| | | | | | | | | | | | whether the timer is currently going is no longer solely dependent on the current game_state: it can be dependent on more persistent information stored in the game_ui. In particular, Mines now freezes the timer permanently once you complete a grid for the first time, so that you can then backtrack through your solution process without destroying the information about how long it took you the first time through. [originally from svn r6088]
* Change of policy on game_changed_state(). Originally, it was calledSimon Tatham2005-07-10
| | | | | | | | | | | | | | | | | | | | | | by the midend every time the game state changed _other_ than as a result of make_move(), on the basis that when the game state changed due to make_move() the game backend had probably noticed anyway. However, when make_move() split up, this became more fiddly: if the game_ui had to be updated based on some property of the final game state, then execute_move() couldn't do it because it didn't have a pointer to the game_ui, but it was fiddly to do it in interpret_move() because that didn't directly have a copy of the finished game state to examine. Same Game (the only game to be affected) had to deal with this by actually having interpret_move() _call_ execute_move() to construct a temporary new game state, update the UI, and then throw it away. So now, game_changed_state() is called _every_ time the current game state changes, which means that if anything needs doing to the game_ui as a result of examining the new game state, it can be done there and save a lot of effort. [originally from svn r6087]
* Subtle UI change to Mines. Although I mostly find the unified left-Simon Tatham2005-07-10
| | | | | | | | | | | | | button interface (same button to open a closed square or to clear around an open one) to be a massive help, there is one circumstance in which it frequently kills me: if I click down on an open square I want to clear around, then the mouse pointer accidentally drifts over on to the nearest closed square before I release, I'll end up opening that square instead and (usually) dying. So this checkin causes Mines to note which type of square I left-clicked on, and to do nothing if the button release is on the other type. [originally from svn r6086]
* Alter the `Octagon' board preset so that instead of presenting youSimon Tatham2005-07-09
| | | | | | | | | with the obvious central hole it presents you with a randomly chosen one of twelve other holes. The reason is, the central-hole starting position is provably insoluble (proof given in comments), so instead we pick from the ones that are actually possible. [originally from svn r6083]
* Missing quit on error was leading to an assertion failure on someSimon Tatham2005-07-06
| | | | | | types of incorrectly formatted save file. [originally from svn r6079]
* Move various printf()s after declarations.Jacob Nevins2005-07-06
| | | | [originally from svn r6078]
generated by cgit v1.1 at 2026-05-08 10:24:06 +0000