aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* OS X frontend was directly calling the backend's wants_statusbar()Simon Tatham2005-10-22
| | | | | | function, whereas it ought to have been calling the midend's one. [originally from svn r6413]
* Cleanup: rename random_init() to random_new(), because it actuallySimon Tatham2005-10-22
| | | | | | | _allocates_ a random_state rather than just initialising one passed in by the caller. [originally from svn r6412]
* New puzzle from James H: `Bridges', another Nikoli job.Simon Tatham2005-10-21
| | | | [originally from svn r6409]
* Miscellaneous fixes. Correct a comparison of y with w causingSimon Tatham2005-10-17
| | | | | | | | | | assertion failures in portrait-type grids; retire an unused array in the game generation function (my original generation strategy needed it, but the final one didn't); correct a typo; further restrict the generable sizes of game and include a special case for 4x4dt to prevent a tight loop. [originally from svn r6405]
* Just noticed a longhand shuffling operation which I must have missedSimon Tatham2005-10-17
| | | | | | when I converted them all into calls to shuffle(). [originally from svn r6404]
* Janes H provides a small workaround for a Palm tools bug.Simon Tatham2005-10-15
| | | | [originally from svn r6403]
* Small error in solver diagnostics.Simon Tatham2005-10-15
| | | | [originally from svn r6402]
* Revamp of the control mechanism to permit drag- as well asSimon Tatham2005-10-14
| | | | | | | click-based control. Only used for right-dragging to clear a large area to NONTENT. [originally from svn r6400]
* New puzzle: `Tents'. Requires a potentially shared algorithms moduleSimon Tatham2005-10-13
| | | | | | | maxflow.c. Also in this checkin, fixes to the OS X and GTK back ends to get ALIGN_VNORMAL right. This is the first time I've used it! :-) [originally from svn r6390]
* loopy_diffnames[] isn't used, and provokes a warning on OS X.Simon Tatham2005-10-13
| | | | [originally from svn r6389]
* Yikes! I've only just noticed that this copy of tree234.c was stillSimon Tatham2005-10-12
| | | | | | | | | using unwrappered malloc/free, leaving plenty of openings for out- of-memory segfaults. Switch to using Puzzles's memory management, which I should have done right at the start but can only assume I forgot about. [originally from svn r6388]
* r6384 didn't go quite far enough. In fact, a grid square whichSimon Tatham2005-10-10
| | | | | | | | | | | | | | differs between oldstate and state in only the hint bit should not have a flip animation even if hints_active is TRUE. Flip animations should only happen for tiles which are changing their primary state. (Put like that, it seems so obvious.) Test case which demonstrates this fix to be right and r6384 to be wrong: 3x3:101000000000000000000,300 . Hit Solve immediately and then click on the red-highlighted squares. [originally from svn r6385] [r6384 == dd175e490a197026210ba4432eec6236971c6173]
* Fixes for handling human-entered Flip games. The clicked-on squareSimon Tatham2005-10-10
| | | | | | | | | | | | always got a flip animation even when it wasn't one of the ones being turned, and a square with no effect at all was still counting as a move. Since it's an invariant of Flip's internal generator that every square includes itself as an effect, this never comes up in auto- generated games. [originally from svn r6384]
* Richard Earnshaw points out that if you enter an out-of-range numberSimon Tatham2005-10-10
| | | | | | | | | in the game description, the solver will fail to notice it and overrun an array leading to assertion failure, silent wrong answers or (in extreme cases) segfaults. Hence, validate_desc() now spots them and kicks them out. [originally from svn r6383]
* Use game_set_size() to set up the temporary drawstate inSimon Tatham2005-09-23
| | | | | | | | | | | | | | | | | | game_print(), wherever feasible. This fixes a specific bug in Loopy (James H's new field ds->linewidth wasn't being set up, leading to corrupted print output), but I've made the change in all affected files because it also seems like a generally good idea to encourage it for future games, to prevent other problems of this type. There is one slight snag, which is that Map _can't_ do this because its game_set_size() also initialises a blitter. I could fix this by abstracting the common parts of Map's game_set_size() out into a subfunction called by game_set_size() and also called directly by game_print(); alternatively, I could introduce a means of determining whether a `drawing *' was for screen or printing use. Not sure which yet. [originally from svn r6340]
* Fix very strange indentation issue!Simon Tatham2005-09-23
| | | | [originally from svn r6339]
* Bug fix from James H: prevent LINEWIDTH ever reaching zero.Simon Tatham2005-09-18
| | | | [originally from svn r6331]
* Another optimisation patch from Mike, which (among other things)Simon Tatham2005-09-18
| | | | | | | | eliminates gratuitous duplication of the solver state every time it goes round the main loop, in favour of the usual type of `done_something' flag. [originally from svn r6322]
* Optimisation patch from Mike: remember which squares we've entirelySimon Tatham2005-09-15
| | | | | | finished dealing with, and don't do them again on the next loop. [originally from svn r6312]
* Patch from Mike: fix an array indexing error in the clueSimon Tatham2005-09-13
| | | | | | highlighting, and adjust the presets. [originally from svn r6303]
* Patch from Mike:Simon Tatham2005-09-12
| | | | | | | | | | | | - remove the backtracking `Hard' level, on the grounds that it was incredibly slow and not really usable. - introduce an `Easy' difficulty level below the standard one; many people seem to find this puzzle unusually hard, so an easy level is particularly helpful. - highlight unfulfillable clue squares (but not yet any other types of obvious error). [originally from svn r6299]
* I am again gormless! When I overhauled Solo's grid generator inSimon Tatham2005-09-12
| | | | | | | | | | r6160, I completely failed to ensure that generated grids were _at most_ the required difficulty. It appears to have been only random chance that prevented a request for a Trivial puzzle from producing Extreme. Here's a one-line fix. [originally from svn r6298] [r6160 == e55838bc9b0d173ca539d0cfe714495b5c12b9dd]
* I found a slightly odd-looking line of code in this file a few daysSimon Tatham2005-09-12
| | | | | | | | ago, and nearly changed it to the obvious thing. After some thought, though, I've decided the `bug' is better off unfixed, and added a comment explaining why. [originally from svn r6293]
* Minor improvement to initial loop generation.Simon Tatham2005-09-11
| | | | [originally from svn r6292]
* Oops; left some rogue diagnostics in.Simon Tatham2005-09-11
| | | | [originally from svn r6291]
* Run the final solution-reduction pass in both directions, sinceSimon Tatham2005-09-11
| | | | | | | | | Gareth managed to find an example (10x8#458168771440033 in r6289) where running it in only one direction failed to eliminate an obviously redundant piece of path. [originally from svn r6290] [r6289 == b25fcc3f2621b0b41f3ae7cdabe57ed07f62d2c2]
* Solve function for Inertia, using what's essentially an approximateSimon Tatham2005-09-11
| | | | | | TSP algorithm. [originally from svn r6289]
* Marginally greater robustness in the face of solve_game() failing toSimon Tatham2005-09-11
| | | | | | return an error message. [originally from svn r6288]
* Completely rewrite the loop-detection algorithm used to check gameSimon Tatham2005-09-10
| | | | | | | | | | | | | | | | | completion, _again_. In r6174 I changed it from dsf to conventional graph theory so that it could actually highlight loops as opposed to just discovering that one existed. Unfortunately, yesterday I discovered a fundamental graph-theoretic error in the latter algorithm: if you had two entirely separate loops connected by a single path, the path would be highlighted as well as the loops. Therefore, I've reverted to the original dsf technique, combined with a subsequent pass to trace around each loop discovered. This version seems to do a better job of only highlighting the actual loops. [originally from svn r6283] [r6174 == 2bd8e241a93165a99f5e2c4a2dd9c3b3b1e3c6f3]
* Patch from James H which initialises a couple of Windows API objectSimon Tatham2005-09-10
| | | | | | handles to NULL before accidentally trying to use them for anything. [originally from svn r6282]
* I arranged that dying after the game was already completed didn'tSimon Tatham2005-09-06
| | | | | | | | increment the deaths counter. In doing so, I incorrectly handled the borderline case, so that a death incurred _in the act_ of collecting the final gem also didn't increment the deaths counter. Now it does. [originally from svn r6277]
* Take the Windows taskbar into account when deciding on the maximumSimon Tatham2005-09-06
| | | | | | | | | | | size of the puzzle window. This has involved some _completely stupid_ window manipulation: in order to figure out in advance how big I want my main window to be, I first have to _create_ the status bar so I know how tall it is; but since I can't reparent it into my main window after I've created it, I then have to throw that status bar away and create a new one. *sigh* [originally from svn r6276]
* Various patches from Ben H: a fix for an outdated comment, a coupleSimon Tatham2005-09-05
| | | | | | | of spurious ps_printf() arguments removed, and an error check in the `make install' target. [originally from svn r6275]
* I've dithered a bit in the past about whether or not it's allowableSimon Tatham2005-09-05
| | | | | | | | | | to call game_set_size() twice on the same drawstate. Finally, a definite decision: it isn't. Accordingly, midend.c arranges never to do so, the devel docs state that puzzles may enforce by assertion that it never happens, and the four puzzles which care (i.e. use blitters) do so. [originally from svn r6274]
* Patch from Ton van Overbeek to fix a small memory leak inSimon Tatham2005-09-04
| | | | | | midend_solve(). [originally from svn r6271]
* Patch from Ton van Overbeek to correct Loopy's misplaced line endsSimon Tatham2005-09-04
| | | | | | at small tile sizes. [originally from svn r6270]
* Another global environment-variable override across all games. ThisSimon Tatham2005-09-04
| | | | | | | one is <game>_TILESIZE, adjusting the game's default size. I anticipate that this will probably _mostly_ be useful for debugging. [originally from svn r6269]
* Couple of minor updates to restore accuracy.Simon Tatham2005-09-04
| | | | [originally from svn r6268]
* Patches from James H. The usual stuff (memory leak fixes and 16-bitSimon Tatham2005-09-03
| | | | | | | | | cleanliness), plus he's enlarged the pencil-mark circles from TILESIZE/8 to TILESIZE/7. Makes no difference at all (thanks to integer division) when TILESIZE is the default of 20, but presumably helps at some other tile sizes. Fine by me. [originally from svn r6265]
* Someone points out that the Solo text formatter would be a lotSimon Tatham2005-09-02
| | | | | | | better if it marked empty cells with something other than a space. So here's a three-bit change to turn it into a dot :-) [originally from svn r6261]
* Stop Light Up from eating system keypresses, which it was previouslySimon Tatham2005-09-01
| | | | | | doing whenever the cursor was active. [originally from svn r6258]
* Optimiser placation.Simon Tatham2005-09-01
| | | | [originally from svn r6257]
* Palm fixes for Loopy from James H: a #ifdef SLOW_SYSTEM, and anSimon Tatham2005-09-01
| | | | | | int/long fix. [originally from svn r6256]
* James H's memory leak fixes to Inertia.Simon Tatham2005-09-01
| | | | [originally from svn r6255]
* James H has implemented a new `Tricky' difficulty level in Light Up:Simon Tatham2005-09-01
| | | | | | | | | | | | | | | | | | a non-recursive level above Easy, which therefore moves the recursive Hard mode further up still. Play-testing suggests that in fact Tricky is often _harder_ than the old Hard mode, since the latter had limited depth of recursion and would therefore spot complex deductions only if it happened to start a recursion on the right square; Tricky may be limited in the sophistication of its complex deductions, but it never misses one, so its puzzles tend to be hard all over. Also in this checkin, a new source file `nullfe.c', containing all the annoying stub functions required to make command-line solvers link successfully. James wrote this for (the new) lightupsolver, and I've used it to simplify the other stand-alone solvers. [originally from svn r6254]
* Ability to drag pencil marks around.Simon Tatham2005-08-31
| | | | [originally from svn r6250]
* Terribly cunning approach to making the pencil marks look nicer,Simon Tatham2005-08-31
| | | | | | thanks to Gareth. [originally from svn r6248]
* Debian requires -lm, where Red Hat didn't.Simon Tatham2005-08-31
| | | | [originally from svn r6247]
* Ahem; forgot about recursion. Recursive solving now shows itsSimon Tatham2005-08-31
| | | | | | working as well. [originally from svn r6245]
* Now that Map has some seriously complex deductions, it's about timeSimon Tatham2005-08-31
| | | | | | | | | | | | it had a command-line solver. In order to do this, I've had to expose the internal region numbering because the solver has to have some way to state which region it means; and in any case it's also useful to have human-visible region numbering so that two people can discuss a puzzle they're solving together. So pressing L during play now toggles the display of region numbers; and `mapsolver' uses those same numbers when showing its working and its solutions. [originally from svn r6244]
generated by cgit v1.1 at 2026-05-02 06:10:27 +0000