aboutsummaryrefslogtreecommitdiff
path: root/list.c (follow)
Commit message (Collapse)AuthorAge
* Fix missing statics and #includes on variables.Simon Tatham2023-02-18
| | | | | | | | | | | | | | | | | | | | | | | After Ben fixed all the unwanted global functions by using gcc's -Wmissing-declarations to spot any that were not predeclared, I remembered that clang has -Wmissing-variable-declarations, which does the same job for global objects. Enabled it in -DSTRICT=ON, and made the code clean under it. Mostly this was just a matter of sticking 'static' on the front of things. One variable was outright removed ('verbose' in signpost.c) because after I made it static clang was then able to spot that it was also unused. The more interesting cases were the ones where declarations had to be _added_ to header files. In particular, in COMBINED builds, puzzles.h now arranges to have predeclared each 'game' structure defined by a puzzle backend. Also there's a new tiny header file gtk.h, containing the declarations of xpm_icons and n_xpm_icons which are exported by each puzzle's autogenerated icon source file and by no-icon.c. Happily even the real XPM icon files were generated by our own Perl script rather than being raw xpm output from ImageMagick, so there was no difficulty adding the corresponding #include in there.
* Migrate to a CMake-based build system.Simon Tatham2021-03-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This completely removes the old system of mkfiles.pl + Recipe + .R files that I used to manage the various per-platform makefiles and other build scripts in this code base. In its place is a CMakeLists.txt setup, which is still able to compile for Linux, Windows, MacOS, NestedVM and Emscripten. The main reason for doing this is because mkfiles.pl was a horrible pile of unmaintainable cruft. It was hard to keep up to date (e.g. didn't reliably support the latest Visual Studio project files); it was so specific to me that nobody else could maintain it (or was even interested in trying, and who can blame them?), and it wasn't even easy to _use_ if you weren't me. And it didn't even produce very good makefiles. In fact I've been wanting to hurl mkfiles.pl in the bin for years, but was blocked by CMake not quite being able to support my clang-cl based system for cross-compiling for Windows on Linux. But CMake 3.20 was released this month and fixes the last bug in that area (it had to do with preprocessing of .rc files), so now I'm unblocked! CMake is not perfect, but it's better at mkfiles.pl's job than mkfiles.pl was, and it has the great advantage that lots of other people already know about it. Other advantages of the CMake system: - Easier to build with. At least for the big three platforms, it's possible to write down a list of build commands that's actually the same everywhere ("cmake ." followed by "cmake --build ."). There's endless scope for making your end-user cmake commands more fancy than that, for various advantages, but very few people _have_ to. - Less effort required to add a new puzzle. You just add a puzzle() statement to the top-level CMakeLists.txt, instead of needing to remember eight separate fiddly things to put in the .R file. (Look at the reduction in CHECKLST.txt!) - The 'unfinished' subdirectory is now _built_ unconditionally, even if the things in it don't go into the 'make install' target. So they won't bit-rot in future. - Unix build: unified the old icons makefile with the main build, so that each puzzle builds without an icon, runs to build its icon, then relinks with it. - Windows build: far easier to switch back and forth between debug and release than with the old makefiles. - MacOS build: CMake has its own .dmg generator, which is surely better thought out than my ten-line bodge. - net reduction in the number of lines of code in the code base. In fact, that's still true _even_ if you don't count the deletion of mkfiles.pl itself - that script didn't even have the virtue of allowing everything else to be done exceptionally concisely.
* I'm sick of repeatedly adding and removing local changes to RecipeSimon Tatham2006-08-05
| | | | | | | | | | | | | | | | | | | | | | when testing a new game, so here's a new architecture for the Recipe file. mkfiles.pl now supports several new features: - an `!include' directive, which accepts wildcards - += to append to an existing object group definition - the ability to divert output to an arbitrary file. So now each puzzle has a `.R' file containing a fragment of Recipe code describing that puzzle, and the central Recipe does `!include *.R' to construct the Makefiles. That way, I can keep as many experimental half-finished puzzles lying around my working directory as I like, and I won't have to keep reverting Recipe when I check in any other changes. As part of this change, list.c is no longer a version-controlled file; it's now constructed by mkfiles.pl, so that it too can take advantage of this mechanism. [originally from svn r6781]
* New puzzle from James H: `Bridges', another Nikoli job.Simon Tatham2005-10-21
| | | | [originally from svn r6409]
* 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]
* 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]
* 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]
* 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]
* 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]
* 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]
* Another game from James H: `Black Box'.Simon Tatham2005-07-17
| | | | [originally from svn r6100]
* 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]
* New puzzle: Dominosa.Simon Tatham2005-07-14
| | | | [originally from svn r6091]
* Peg Solitaire implementation, complete with a random boardSimon Tatham2005-07-04
| | | | | | | generator. The generator is lacking in almost any kind of finesse, but it produces puzzles which at least _I_ find plausibly puzzling. [originally from svn r6052]
* `Guess', a Mastermind clone from James Harvey. This checkin alsoSimon Tatham2005-06-23
| | | | | | | | introduces a few new utility functions in misc.c, one of which is the bitmap obfuscator from Mines (which has therefore been moved out of mines.c). [originally from svn r5992]
* Another new puzzle! This one isn't particularly deep or complexSimon Tatham2005-06-17
| | | | | | | | | (solving it only requires matrix inversion over GF(2), whereas several of the other puzzles in this collection are NP-complete in principle), but it's a fun enough thing to play with and is non-trivial to do in your head - especially on the hardest preset. [originally from svn r5967]
* Forgot to add Same Game to the big list for OS X.Simon Tatham2005-06-07
| | | | [originally from svn r5918]
* Initial checkin of my Minesweeper clone, which uses a solver duringSimon Tatham2005-05-30
| | | | | | grid generation to arrange a mine layout that never requires guessing. [originally from svn r5859]
* New puzzle: `twiddle', generalised from a random door-unlockingSimon Tatham2005-04-30
| | | | | | gadget in Metroid Prime 2. [originally from svn r5708]
* Initial checkin of `Solo', the number-placing puzzle popularised bySimon Tatham2005-04-23
| | | | | | the Times under the name `Sudoku'. [originally from svn r5660]
* Arrange that we really _can_ compile all the puzzles into a singleSimon Tatham2005-01-22
binary if we choose: fix bugs in cube.c and sixteen.c that manifest when compiled that way, and introduce list.c which provides a global list of all the available puzzles. [originally from svn r5169]