aboutsummaryrefslogtreecommitdiff
path: root/puzzles.h (follow)
Commit message (Collapse)AuthorAge
...
* Return error messages as 'const char *', not 'char *'.Simon Tatham2017-10-01
| | | | | They're never dynamically allocated, and are almost always string literals, so const is more appropriate.
* Use a proper union in struct config_item.Simon Tatham2017-10-01
| | | | | | This allows me to use different types for the mutable, dynamically allocated string value in a C_STRING control and the fixed constant list of option names in a C_CHOICES.
* New name UI_UPDATE for interpret_move's return "".Simon Tatham2017-10-01
| | | | | | | | | | | | | Now midend.c directly tests the returned pointer for equality to this value, instead of checking whether it's the empty string. A minor effect of this is that games may now return a dynamically allocated empty string from interpret_move() and treat it as just another legal move description. But I don't expect anyone to be perverse enough to actually do that! The main purpose is that it avoids returning a string literal from a function whose return type is a pointer to _non-const_ char, i.e. we are now one step closer to being able to make this code base clean under -Wwrite-strings.
* Generate special fake keypresses from menu options.Simon Tatham2017-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes an amusing UI bug that I think can currently only come up in the unpublished puzzle 'Group', but there's no reason why other puzzles _couldn't_ do the thing that triggers the bug, if they wanted to. Group has unusual keyboard handling, in that sometimes (when a cell is selected for input and the key in question is valid for the current puzzle size) the game's interpret_move function will eat keystrokes like 'n' and 'u' that would otherwise trigger special UI events like New Game or Undo. The bug is that fake keypress events generated from the GUI menus looked enough like those keystrokes that interpret_move would eat those too. So if you start, say, a 16x16 Group puzzle, select an empty cell, and then choose 'new game' from the menu, Group will enter 'n' into the cell instead of starting a new game! I've fixed this by inventing a new set of special keystroke values called things like UI_NEWGAME and UI_UNDO, and having the GUI menus in all my front ends generate those in place of 'n' and 'u'. So now the midend can tell the difference between 'n' on the keyboard and New Game from the menu, and so Group can treat them differently too. In fact, out of sheer overcaution, midend.c will spot keystrokes in this range and not even _pass_ them to the game back end, so Group shouldn't be able to override these special events even by mistake. One fiddly consequence is that in gtk.c I've had to rethink the menu accelerator system. I was adding visible menu accelerators to a few menu items, so that (for example) 'U' and 'R' showed up to the right of Undo and Redo in the menu. Of course this had the side effect of making them real functioning accelerators from GTK's point of view, which activate the menu item in the same way as usual, causing it to send whatever keystroke the menu item generates. In other words, whenever I entered 'n' into a cell in a large Group game, this was the route followed by even a normal 'n' originated from a real keystroke - it activated the New Game menu item by mistake, which would then send 'n' by mistake instead of starting a new game! Those mistakes cancelled each other out, but now I've fixed the latter, I've had to fix the former too or else the GTK front end would now undo all of this good work, by _always_ translating 'n' on the keyboard to UI_NEWGAME, even if the puzzle would have wanted to treat a real press of 'n' differently. So I've fixed _that_ in turn by putting those menu accelerators in a GtkAccelGroup that is never actually enabled on the main window, so the accelerator keys will be displayed in the menu but not processed by GTK's keyboard handling. (Also, while I was redoing this code, I've removed the logic in add_menu_item_with_key that reverse-engineered an ASCII value into Control and Shift modifiers plus a base key, because the only arguments to that function were fixed at compile time anyway so it's easier to just write the results of that conversion directly into the call sites; and I've added the GTK_ACCEL_LOCKED flag, in recognition of the fact that _because_ these accelerators are processed by a weird mechanism, they cannot be dynamically reconfigured by users and actually work afterwards.)
* Work around non-compliant sprintf().Franklin Wei2017-04-30
| | | | | | | | Rockbox's sprintf() lacks the ability to left-justify a string. Fixed by adding a copy_left_justfied() function to misc.c. This is a new version of this commit, as the previous version broke saving!
* Rework the preset menu system to permit submenus.Simon Tatham2017-04-26
| | | | | | | | | | | | | | | | | | | | To do this, I've completely replaced the API between mid-end and front end, so any downstream front end maintainers will have to do some rewriting of their own (sorry). I've done the necessary work in all five of the front ends I keep in-tree here - Windows, GTK, OS X, Javascript/Emscripten, and Java/NestedVM - and I've done it in various different styles (as each front end found most convenient), so that should provide a variety of sample code to show downstreams how, if they should need it. I've left in the old puzzle back-end API function to return a flat list of presets, so for the moment, all the puzzle backends are unchanged apart from an extra null pointer appearing in their top-level game structure. In a future commit I'll actually use the new feature in a puzzle; perhaps in the further future it might make sense to migrate all the puzzles to the new API and stop providing back ends with two alternative ways of doing things, but this seemed like enough upheaval for one day.
* New centralised loop-finder, using Tarjan's algorithm.Simon Tatham2016-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | In the course of another recent project I had occasion to read up on Tarjan's bridge-finding algorithm. This analyses an arbitrary graph and finds 'bridges', i.e. edges whose removal would increase the number of connected components. This is precisely the dual problem to error-highlighting loops in games like Slant that don't permit them, because an edge is part of some loop if and only if it is not a bridge. Having understood Tarjan's algorithm, it seemed like a good idea to actually implement it for use in these puzzles, because we've got a long and dishonourable history of messing up the loop detection in assorted ways and I thought it would be nice to have an actually reliable approach without any lurking time bombs. (That history is chronicled in a long comment at the bottom of the new source file, if anyone is interested.) So, findloop.c is a new piece of reusable library code. You run it over a graph, which you provide in the form of a vertex count and a callback function to iterate over the neighbours of each vertex, and it fills in a data structure which you can then query to find out whether any given edge is part of a loop in the graph or not.
* Insert a manual reference in the default status bar text.Jonas Kölker2015-10-03
| | | | | | To guide developers to the resources they need. [actual wording tweaked by SGT]
* 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]
* Add 'const' to the game_params arguments in validate_desc andSimon Tatham2013-04-12
| | | | | | | | | | | | new_desc. Oddities in the 'make test' output brought to my attention that a few puzzles have been modifying their input game_params for various reasons; they shouldn't do that, because that's the game_params held permanently by the midend and it will affect subsequent game generations if they modify it. So now those arguments are const, and all the games which previously modified their game_params now take a copy and modify that instead. [originally from svn r9830]
* Add a new midend function to reset the tile size to the puzzle'sSimon Tatham2013-04-07
| | | | | | | default (but still counting the <puzzle>_TILESIZE user preference environment variables, where available). [originally from svn r9820]
* I've just realised that the JS puzzles' permalinks were not updatingSimon Tatham2013-04-05
| | | | | | | | | | | | | | | when the user pressed 'n' for a new game, because all the front end knows is that it passed a keystroke to the puzzle, and it has no way of hearing back that a particular keypress resulted in a game id change. To fix this, I've renamed midend_request_desc_changes to midend_request_id_changes and expanded its remit to cover _any_ change to the game ids. So now that callback in the Emscripten front end is the only place from which update_permalinks is called (apart from initialising them at setup time), and that should handle everything. [originally from svn r9805]
* Introduce a mechanism by which calls to midend_supersede_game_desc()Simon Tatham2013-03-31
| | | | | | | can trigger a call to a front end notification function. Use this to update the game ID permalink when Mines supersedes its game ID. [originally from svn r9793]
* Add a midend function to return the current random seed, parallel toSimon Tatham2013-03-30
| | | | | | | the existing one that returns the game id. No front end has so far needed this, but one is about to. [originally from svn r9778]
* Revamp of the Windows command-line parsing and puzzle-loading code.Simon Tatham2013-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows puzzles now accept similar command-line syntax to the GTK ones, in that you can give them either a game ID (descriptive, random or just plain params) or the name of a save file. Unlike the GTK ones, however, the save file interpretation is tried first; this is because some puzzles (e.g. Black Box) will interpret any old string as a valid (if boring) game ID, and unlike the GTK puzzles it's not feasible to require users to disambiguate via a command-line option, because on Windows a thing that might easily happen is that a user passes a save file to a puzzle binary via 'Open With' in the GUI shell, where they don't get the chance to add extra options. In order to make this work sensibly in the all-in-one Windows app, I had to get round to another thing I've been planning to do for a while, which is to write a function to examine a saved game file and find out which puzzle it's for. So the combined Windows binary will auto-switch to the right game if you pass a save file on its command line, and also if you use Load while the program is running. Another utility function I needed is one to split the WinMain single command line string into argv. For this I've imported a copy of split_into_argv() from Windows PuTTY (which doesn't affect this package's list of copyright holders, since that function was all my own code anyway). [originally from svn r9749]
* New rule: interpret_move() is passed a pointer to the game_drawstateSimon Tatham2012-09-09
| | | | | | | | | | | | | | | | basically just so that it can divide mouse coordinates by the tile size, but is definitely not expected to _write_ to it, and it hadn't previously occurred to me that anyone might try. Therefore, interpret_move() now gets a pointer to a _const_ game_drawstate instead of a writable one. All existing puzzles cope fine with this API change (as long as the new const qualifier is also added to a couple of subfunctions to which interpret_move delegates work), except for the just-committed Undead, which somehow had ds->ascii and ui->ascii the wrong way round but is otherwise unproblematic. [originally from svn r9657]
* New puzzle! Or rather, new-ish, because this one has been lying aroundSimon Tatham2012-01-22
| | | | | | | | | | | | | in the 'unfinished' directory for a while, and has now been finished up thanks to James Harvey putting in some effort and galvanising me to put in the rest. This is 'Pearl', an implementation of Nikoli's 'Masyu'. The code in Loopy that generates a random loop along grid edges to use as the puzzle solution has been abstracted out into loopgen.[ch] so that Pearl can use it for its puzzle solutions too. I've also introduced a new utility module called 'tdq' (for 'to-do queue'). [originally from svn r9379]
* Changed my mind about midend_is_solved: I've now reprototyped it asSimon Tatham2011-06-19
| | | | | | | | | | | | | | | | midend_status(), and given it three return codes for win, (permanent) loss and game-still-in-play. Depending on what the front end wants to use it for, it may find any or all of these three states worth distinguishing from each other. (I suppose a further enhancement might be to add _non_-permanent loss as a fourth distinct status, to describe situations in which you can't play further without pressing Undo but doing so is not completely pointless. That might reasonably include dead-end situations in Same Game and Pegs, and blown-self-up situations in Mines and Inertia. However, I haven't done this at present.) [originally from svn r9179]
* Add a function to every game backend which indicates whether a gameSimon Tatham2011-04-02
| | | | | | | | | | | state is in a solved position, and a midend function wrapping it. (Or, at least, a situation in which further play is pointless. The point is, given that game state, would it be a good idea for a front end that does that sort of thing to proactively provide the option to start a fresh game?) [originally from svn r9140]
* Add functions provided by the midend to tell a front end whether GUISimon Tatham2011-04-02
| | | | | | buttons for undo and redo should currently be greyed out. [originally from svn r9139]
* Patch from Mark Wooding to introduce a draw_thick_line() function inSimon Tatham2010-05-29
| | | | | | | | | | | | the drawing API, for use by Loopy. It's optional: drawing.c will construct an acceptable alternative using a filled polygon if the front end doesn't provide it. Net and Netslide previously had static functions called draw_thick_line(), whose claim to the name is less justified and so they've been renamed. [originally from svn r8962]
* Introduce, and implement as usefully as I can in all front ends, aSimon Tatham2009-12-27
| | | | | | | | | | new function in the drawing API which permits the display of text from outside basic ASCII. A fallback mechanism is provided so that puzzles can give a list of strings they'd like to display in order of preference and the system will return the best one it can manage; puzzles are required to cope with ASCII-only front ends. [originally from svn r8793]
* Keyboard control for Dominosa (patch largely due to James H, thoughSimon Tatham2009-12-22
| | | | | | with considerable meddling from me). [originally from svn r8788]
* Patch from James H to abstract out of Dominosa the code whichSimon Tatham2009-03-02
| | | | | | | randomly generates a tiling of a rectangle with dominoes, since he wants to reuse that function in another puzzle. [originally from svn r8488]
* Introduce some infrastructure to permit games' print functions toSimon Tatham2009-02-22
| | | | | | draw dotted lines. No puzzle yet uses this, but one's about to. [originally from svn r8453]
* Patch from James H to add keyboard control in Sixteen and NetslideSimon Tatham2009-01-26
| | | | | | (and also belatedly document the keyboard support in Unequal). [originally from svn r8432]
* Patch from James H to enable a single monolithic binary to be builtSimon Tatham2009-01-06
| | | | | | | | alongside the individual puzzle binaries, on Windows only. (MacOS already has it, of course; Unix would require about as much work again.) [originally from svn r8396]
* Patch from James H to centralise some generally useful cursor-Simon Tatham2008-09-13
| | | | | | handling functionality into misc.c. [originally from svn r8176]
* New infrastructure feature. Games are now permitted to beSimon Tatham2008-09-06
| | | | | | | | | | | | | | | | | | | | | | _conditionally_ able to format the current puzzle as text to be sent to the clipboard. For instance, if a game were to support playing on a square grid and on other kinds of grid such as hexagonal, then it might reasonably feel that only the former could be sensibly rendered in ASCII art; so it can now arrange for the "Copy" menu item to be greyed out depending on the game_params. To do this I've introduced a new backend function (can_format_as_text_now()), and renamed the existing static backend field "can_format_as_text" to "can_format_as_text_ever". The latter will cause compile errors for anyone maintaining a third-party front end; if any such person is reading this, I apologise to them for the inconvenience, but I did do it deliberately so that they'd know to update their front end. As yet, no checked-in game actually uses this feature; all current games can still either copy always or copy never. [originally from svn r8161]
* New feature in midend.c which allows us to ask for the number of theSimon Tatham2008-04-08
| | | | | | | | | | currently selected preset, if any. I've used this in the GTK front end to have the Type menu mark the currently selected menu item. (After considerable beating of GTK with sticks, I might add. Grr.) Currently the same UI feature is not yet supported on Windows or MacOS, but I hope to do those too at some point if it's feasible. [originally from svn r7980]
* Ahem. Apparently forgot to compile-test after that one last tinySimon Tatham2008-04-07
| | | | | | change. [originally from svn r7977]
* Revise the printing colour framework so that we can explicitlySimon Tatham2008-04-07
| | | | | | | request either of hatching or halftoning, and also choose which to supply as a fallback when printing in colour. [originally from svn r7976]
* Substantial reworking of Solo so that it implements both Sudoku-XSimon Tatham2008-04-07
| | | | | | | | | | | | | | | | | | | | | | | | | | (require both main diagonals to have one of every digit in addition to all the usual constraints) and Jigsaw Sudoku (replace the array of rectangular sub-blocks with the sub-blocks being random polyominoes). To implement the latter, I've moved my `divvy.c' library routine out of the `unfinished' subdirectory. Jigsaw mode is currently an undocumented feature: you enable it by setting the rows parameter to 1 (and the columns parameter to your desired grid size, which unlike normal Sudoku can be anything you like including a prime number). The reason it's undocumented is because generation times are not yet reliably short: sometimes generating a jigsaw-type puzzle can hang for hours and still get nowhere. (The algorithm should terminate in principle, but not in any time you're prepared to wait.) I _think_ I know how to solve this, but have yet to try it. Until then, jigsaw mode will remain a hidden feature. Printing of X-type puzzles is also substandard at present, because the current print-colour API replaces the desired light shading of the X-cells with heavy diagonal hatching. I plan to adjust the API imminently to address this. [originally from svn r7974]
* 64-bit cleanliness: we were already carefully using a uint32 type inSimon Tatham2007-12-15
| | | | | | the SHA code, but it wasn't correctly defined! [originally from svn r7817]
* Add a new misc.c function needed by Slide's colour setup.Simon Tatham2007-05-07
| | | | [originally from svn r7552]
* Since we've changed the semantics of the `expand' argument to midend_size(),Jacob Nevins2007-03-03
| | | | | | change the name. Also document the new semantics. [originally from svn r7369]
* Provide my old drag-based interface to Net as an ifdef-enabledSimon Tatham2007-02-27
| | | | | | | option, and turn it on by default on stylus-based platforms (i.e. currently PocketPC). [originally from svn r7341]
* Dariusz Olszewski's changes to support compiling for PocketPC. ThisSimon Tatham2007-02-26
| | | | | | | | | | | | is mostly done with ifdefs in windows.c; so mkfiles.pl generates a new makefile (Makefile.wce) and Recipe enables it, but it's hardly any different from Makefile.vc apart from a few definitions at the top of the files. Currently the PocketPC build is not enabled in the build script, but with any luck I'll be able to do so reasonably soon. [originally from svn r7337]
* New puzzle: `Filling', a Fillomino implementation by Jonas Koelker.Simon Tatham2007-02-25
| | | | [originally from svn r7326]
* New mechanism for automatic generation of the puzzle screenshots onSimon Tatham2006-12-26
| | | | | | | | | | | | | | | | | | | the web, which I hope will also end up being extended to generate both Windows and X icons for each individual puzzle. The mechanism is: for each puzzle there's a save file in the `icons' subdirectory showing a game state which I think is a decent illustration of the puzzle, and then there's a nasty set of scripts which runs each puzzle binary, loads that save file, grabs a screenshot using xwd, and munges it into shape. In order to support this I've added two new options (--redo and --windowid) to all the GTK puzzles, which I don't expect ever to be used outside the icons makefile. I've also added two more options (--load and --id) which force a GTK puzzle to treat its command-line option as a save file or as a game ID respectively (the previous behaviour was always to guess, and sometimes it guessed wrong). [originally from svn r7014]
* HTML Help support for Puzzles, with the same kind of automaticSimon Tatham2006-12-24
| | | | | | fallback behaviour as PuTTY's support. [originally from svn r7009]
* Mike Pinna has done some major reworking of the Loopy solver, givingSimon Tatham2006-10-28
| | | | | | rise to a new Hard difficulty level. [originally from svn r6880]
* Extra utility function.Simon Tatham2006-08-05
| | | | [originally from svn r6780]
* Cleanup: relieve frontends of the duty to callSimon Tatham2005-10-22
| | | | | | | | | | | | | midend_rewrite_statusbar() and check the result against the last string returned. This is now done centrally in drawing.c, and the front end status bar function need only do what it says on the tin. While I'm modifying the prototype of drawing_init(), I've also renamed it drawing_new() for the same reason as random_new() (it _allocates_ a drawing object, rather than just initialising one passed in). [originally from svn r6420]
* Cleanup: it was absolutely stupid for game_wants_statusbar() to be aSimon Tatham2005-10-22
| | | | | | | | | function, since it took no parameters by which to vary its decision, and in any case it's hard to imagine a game which only _conditionally_ wants a status bar. Changed it into a boolean data field in the backend structure. [originally from svn r6417]
* Cleanup: remove the game_state parameter to game_colours(). No gameSimon Tatham2005-10-22
| | | | | | | | | | | | was actually using it, and also it wasn't being called again for different game states or different game parameters, so it would have been a mistake to depend on anything in that game state. Games are now expected to commit in advance to a single fixed list of all the colours they will ever need, which was the case in practice already and simplifies any later port to a colour-poor platform. Also this change has removed a lot of unnecessary faff from midend_colours(). [originally from svn r6416]
* Cleanup: the `mouse_priorities' field in the back end has been aSimon Tatham2005-10-22
| | | | | | | more general-purpose flags word for some time now. Rename it to `flags'. [originally from svn r6414]
* 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]
* 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]
* 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]
generated by cgit v1.1 at 2026-04-24 22:28:25 +0000