aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Forcing chains in Map give rise to a new `Hard' difficulty level.Simon Tatham2005-08-30
| | | | | | | Also implemented the Map analogue of Solo's pencil marks, to make this mode more playable. [originally from svn r6240]
* Implemented a couple more reasoning modes for Extreme difficultySimon Tatham2005-08-30
| | | | | | | | | | | | | | level: positional set elimination (which is so obvious I really should have thought of it myself, though it's tricky to spot) and forcing chains (which are a type of one-level proof by contradiction, findable through a simple breadth-first search without requiring recursion, but so ludicrously powerful that they are able to solve _two thirds_ of grids that the pre-Extreme Solo generated and rated as Unreasonable). Of course this makes Unreasonable mode harder still... [originally from svn r6239]
* Backspace and Delete keys now function like Space in Solo.Simon Tatham2005-08-29
| | | | [originally from svn r6237]
* Typo in comment :-)Simon Tatham2005-08-29
| | | | [originally from svn r6236]
* Ahem. The region density at which things start to get hairy is 2/3Simon Tatham2005-08-29
| | | | | | of the grid area, not 3/2! [originally from svn r6235]
* Aesthetic improvements to the Map error indicators:Simon Tatham2005-08-29
| | | | | | | | | - the exclamation mark was a bit dot-heavy - allowing the indicator to be placed at a grid point as well as half way between two grid points allows some much more natural positioning. [originally from svn r6234]
* Unreasonable mode for Map.Simon Tatham2005-08-28
| | | | [originally from svn r6229]
* Error highlighting in Map.Simon Tatham2005-08-28
| | | | [originally from svn r6228]
* There seems to be some odd behaviour when GTK is asked to draw anSimon Tatham2005-08-28
| | | | | | | | outline polygon with a clipping rectangle active. I don't know or care whether this is GTK or my X server or what, but I'm working around it by drawing the lines myself, which seems to sort it out. [originally from svn r6227]
* HACKING.but -> devel.butJacob Nevins2005-08-28
| | | | [originally from svn r6226]
* Fix array bounds violation in the solver. Oops.Simon Tatham2005-08-27
| | | | [originally from svn r6225]
* OS X seems particularly picky about possibly uninitialisedSimon Tatham2005-08-27
| | | | | | variables. Placate its optimiser (again). [originally from svn r6223]
* New puzzle: `Inertia', originally written for Windows by BenSimon Tatham2005-08-27
| | | | | | | Olmstead and reimplemented with the help of his source code which he was kind enough to release into the public domain. [originally from svn r6222]
* Trivial doc changes after recent prolificacy.Jacob Nevins2005-08-26
| | | | [originally from svn r6220]
* Memory leak and type safety fixes from James H.Simon Tatham2005-08-25
| | | | [originally from svn r6219]
* Phil Bordelon points out that the general convention is to orientSimon Tatham2005-08-25
| | | | | | rectangular presets in a portrait fashion. [originally from svn r6217]
* Mike points out that I made an error in one of the presets...Simon Tatham2005-08-25
| | | | [originally from svn r6216]
* Over-enthusiastic assertion introduced in the printing revamp wasSimon Tatham2005-08-24
| | | | | | causing Mines to crash one second after starting a game. Oops. [originally from svn r6214]
* Optimiser placation for OS X gcc.Simon Tatham2005-08-24
| | | | [originally from svn r6212]
* New puzzle: `Loopy', an implementation of Nikoli's `Slither Link' orSimon Tatham2005-08-24
| | | | | | `Loop the Loop' puzzle. Contributed by Mike Pinna. [originally from svn r6211]
* Minor update to Solo's documentation due to Extreme mode.Simon Tatham2005-08-24
| | | | [originally from svn r6210]
* Brand new difficulty level in Solo. The other day Gareth and ISimon Tatham2005-08-24
| | | | | | | | | | | | | | | | independently discovered an advanced reasoning technique in Map, and then it occurred to me that since Solo can also be considered as a graph-colouring game the same technique ought to be applicable. And it is; so here's a new difficulty level, `Extreme', which sits just above Advanced. Grids graded `Extreme' by new-Solo will of course fall into old-Solo's `Unreasonable' category (since they're not soluble using the old set of non-recursive methods). A brief and unscientific experiment suggests that about one in six Unreasonable grids generated by old-Solo are classified Extreme by the new solver; so the remaining Unreasonable mode (now containing a subset of the grids it used to) hasn't actually become much harder. [originally from svn r6209]
* Don't report an error when loading a saved game from the commandSimon Tatham2005-08-23
| | | | | | line unless there really _is_ an error! [originally from svn r6203]
* James H points out a rogue fprintf in Net's print routine.Simon Tatham2005-08-22
| | | | [originally from svn r6202]
* Memory leak in the new printing stuff, plus a couple of commentSimon Tatham2005-08-22
| | | | | | corrections. [originally from svn r6199]
* `Solve' operation on an already solved map without an aux_info wasSimon Tatham2005-08-22
| | | | | | | returning NULL due to no moves being required, leading to a strange error message. Trivial fix. [originally from svn r6198]
* *blinks* I apparently didn't try _building_ the OS X port since theSimon Tatham2005-08-21
| | | | | | | printing upheaval. I could have sworn I had. Oh well; small errors fixed. [originally from svn r6197]
* Retire redundant print_line_width() in Net: a relic from a failedSimon Tatham2005-08-20
| | | | | | printing strategy, irrelevant to the one which worked. [originally from svn r6194]
* Native Windows printing support, using the infrastructure I put inSimon Tatham2005-08-20
| | | | | | | | | | | | | | | | | | | | | place in r6190. I'm quite pleased that I didn't have to modify the printing infrastructure _at all_ to make this work; the only source change required outside windows.c was the addition of a trivial utility function midend_get_params(), and that was for the benefit of bulk puzzle generation rather than anything to do with actual printing. As far as I can tell, all printable puzzles now print almost indistinguishably from the way they print under Unix. If you look closely the font is slightly different, and the Windows standard hatching doesn't seem to be quite as nice as the kind I did by hand in ps.c (and, particularly annoyingly, hatched areas don't show up at all for me when I print to a file and use gv, though they come out fine on the printer itself); but it's all there, and it all works. [originally from svn r6193] [r6190 == af59dcf6858264103bbc621761feee3aed5aaf2a]
* Richard B points out a cut and paste error.Simon Tatham2005-08-19
| | | | [originally from svn r6192]
* Bah, there's always one. Remove the now-erroneous `*.py' from theSimon Tatham2005-08-19
| | | | | | makedist script. [originally from svn r6191]
* Substantial infrastructure upheaval. I've separated the drawing APISimon Tatham2005-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as seen by the back ends from the one implemented by the front end, and shoved a piece of middleware (drawing.c) in between to permit interchange of multiple kinds of the latter. I've also added a number of functions to the drawing API to permit printing as well as on-screen drawing, and retired print.py in favour of integrated printing done by means of that API. The immediate visible change is that print.py is dead, and each puzzle now does its own printing: where you would previously have typed `print.py solo 2x3', you now type `solo --print 2x3' and it should work in much the same way. Advantages of the new mechanism available right now: - Map is now printable, because the new print function can make use of the output from the existing game ID decoder rather than me having to replicate all those fiddly algorithms in Python. - the new print functions can cope with non-initial game states, which means each puzzle supporting --print also supports --with-solutions. - there's also a --scale option permitting users to adjust the size of the printed puzzles. Advantages which will be available at some point: - the new API should permit me to implement native printing mechanisms on Windows and OS X. [originally from svn r6190]
* Just noticed another thing that could easily catch me out whenSimon Tatham2005-08-15
| | | | | | adding a new puzzle. [originally from svn r6189]
* Memory leak fixes from James H.Simon Tatham2005-08-13
| | | | [originally from svn r6188]
* New puzzle: `Map'. Vaguely original, for a change.Simon Tatham2005-08-13
| | | | | | | | | | (This puzzle is theoretically printable, but I haven't added it in print.py since there's rather a lot of painful processing required to get from the game ID to the puzzle's visual appearance. It probably won't become printable unless I get round to implementing a more integrated printing architecture.) [originally from svn r6186]
* 16-bit-cleanness fixes from James H (again). It would be really niceSimon Tatham2005-08-11
| | | | | | | | | | to have some means of automatically spotting this sort of problem on a desktop platform, but I can't immediately think of one; building a trick compiler which thinks `int' is 16 bits would be the obvious option, but it would immediately break the ABIs to all the system functions. [originally from svn r6184]
* Very fiddly corrections to the loop highlighting. ERRSLASH means theSimon Tatham2005-08-09
| | | | | | | | | | | slash in this square is red, so it does indeed imply that some of the edge markings are also red; but it doesn't mean _all_ the edge markings must be red. So instead of assuming ERRSLASH implies all edge error markers, we set the correct set of edge error markers at the same time as setting ERRSLASH, at which point we know which kind of slash it is so we know which ones to set. [originally from svn r6175]
* Implement error checking in Slant. Clue points are now highlightedSimon Tatham2005-08-09
| | | | | | | | | | | | | | | in red if it's impossible to fulfill them (either through too many neighbours connecting to them, or too many not connecting to them), and edges are highlighted in red if they form part of a loop. In order to do this I've had to revamp the redraw function considerably. Each square is now drawn including its top and left grid edges, but _not_ its bottom or right ones - which means that I need to draw an extra strip of empty squares outside the actual grid in order to draw the few pixels which appear on the grid bottom and right borders and also to red-highlight border clues. [originally from svn r6174]
* Remove conditional definition of MAX_GRIDGEN_TRIES, for consistencySimon Tatham2005-08-07
| | | | | | between Palm and other ports when fed the same random seed. [originally from svn r6172]
* Placate optimiser.Simon Tatham2005-08-07
| | | | [originally from svn r6171]
* Streamline `slantsolver' a bit (avoid showing advanced working onSimon Tatham2005-08-06
| | | | | | | easy puzzles, and stop having a second encoding of the difficulty levels). [originally from svn r6170]
* Document hard mode in Slant, and also fix an obvious memorySimon Tatham2005-08-06
| | | | | | management error in game_configure(). [originally from svn r6169]
* Introduce an environment variable setting (SLANT_SWAP_BUTTONS=yes)Simon Tatham2005-08-06
| | | | | | | | | | | to reverse the effect of the mouse buttons. Gareth has been complaining about this for days: apparently he finds precisely the opposite control system intuitive to me. This is a horrendous hack, and pushes me one step closer to losing my temper and designing a proper preferences architecture. [originally from svn r6168]
* A bunch of new reasoning techniques in the Slant solver, leading toSimon Tatham2005-08-06
| | | | | | | a new Hard mode. Also added a command-line `slantsolver' which can grade puzzles and show working. [originally from svn r6167]
* Cleanups to completion flashes: all four of these games used toSimon Tatham2005-08-05
| | | | | | | | | redraw the whole window _every_ time game_redraw() was called during a flash. Now they only redraw the whole window every time the background colour actually changes. Thanks to James H for much of the work. [originally from svn r6166]
* New puzzle: `Light Up', by James H.Simon Tatham2005-08-04
| | | | | | | | | | Also in this checkin (committed by mistake - I meant to do it separately), a behind-the-scenes change to Slant to colour the two non-touching classes of diagonals in different colours. Both colours are set to black by default, but configuration by way of SLANT_COLOUR_* can distinguish them if you want. [originally from svn r6164]
* Environment-based configuration wasn't sensibly usable in games withSimon Tatham2005-08-04
| | | | | | | spaces in the name. Fixed. (One day I really must get round to turning this into a proper config mechanism.) [originally from svn r6163]
* Patch from James H: tinker with the presets on SLOW_SYSTEMs.Simon Tatham2005-08-04
| | | | [originally from svn r6162]
* Bug fix from James H: solve_game() was returning error messages inSimon Tatham2005-08-04
| | | | | | | | the return value rather than in *error. In the old days type- checking would have caught this, but now of course they're the same type. [originally from svn r6161]
* I am COMPLETELY GORMLESS. The Solo grid generator, when eliminatingSimon Tatham2005-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | clues from a filled grid, was using the algorithm - loop over the whole grid looking for a clue (or symmetry group of clues) which can be safely removed - remove it - loop over the whole grid again, and so on. This was due to my vague feeling that removing one clue might affect whether another can be removed. Of course this can happen - two clues can be alternative ways of deducing the same vital fact so that removing one makes the other necessary - but what _can't_ happen is for removing one clue to make another _become_ removable, since you can only do that by _adding_ information. In other words, after testing a clue and determining that it can't be removed, you never need to test it again. Thus, a much simpler algorithm is - loop over the possible clues (or symmetry groups) _once_, in a random order - for each clue (group), if it is removable, remove it. This still guarantees to leave the grid in a state where no further clues can be removed, but it greatly cuts down puzzle generation time and also simplifies the code. I am a fool for not having spotted this in three and a half months! [originally from svn r6160]
generated by cgit v1.1 at 2026-05-01 23:50:37 +0000