aboutsummaryrefslogtreecommitdiff
path: root/.gitignore (follow)
Commit message (Collapse)AuthorAge
* New puzzle: 'Mosaic'.Simon Tatham2021-04-25
| | | | | | | | | | | | | | | | | | This is similar in concept to Minesweeper, in that each clue tells you the number of things (in this case, just 'black squares') in the surrounding 3x3 grid section. But unlike Minesweeper, there's no separation between squares that can contain clues, and squares that can contain the things you're looking for - a clue square may or may not itself be coloured black, and if so, its clue counts itself. So there's also no hidden information: the clues can all be shown up front, and the difficulty arises from the game generator choosing which squares to provide clues for at all. Contributed by a new author, Didi Kohen. Currently only has one difficulty level, but harder ones would be possible to add later.
* Add .gitignore rules for in-tree builds.Simon Tatham2021-04-19
| | | | | | | This set of rules should cover make and ninja on Linux, and all of nmake, ninja and vcxproj on Windows, so that if someone follows the README build instructions (by doing 'cmake .' in-tree), it should generate no debris that .gitignore can't filter out.
* 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.
* Tracks: add standalone solver program.Simon Tatham2020-02-26
| | | | | | | Having one of these makes it much easier to debug what's going on when the solver can't solve something. Also, now the solver can grade the difficulty of a puzzle, it's useful to expose that feature in a command-line tool.
* .gitignore: add more autotools detritus.Simon Tatham2019-11-13
| | | | | | | One of these days I should sit down and work out exactly when a run of autoconf generates an autom4te.cache directory, and why it can suddenly turn up unexpectedly one day after years of never needing to put it in .gitignore!
* Dominosa: add a command-line solver.Simon Tatham2019-04-04
| | | | | | I've made the existing optional solver diagnostics appear as the verbose output of the solver program. They're not particularly legible at the moment, but they're better than nothing.
* Add missing binary 'matching' to .gitignore.Simon Tatham2018-11-13
|
* Enable 64-bit osx build and fix a warning.Josh Lee2018-06-01
| | | | | | OS X is beginning to show a warning when a 32-bit application is opened, so it's high time that this gets enabled. Fix a clang warning exposed by this build.
* Add patternpicture to .gitignore.Phil Bordelon2016-02-14
|
* Add the new 'fifteensolver' to .gitignore.Simon Tatham2015-10-18
|
* Add a new puzzle: Palisade.Jonas Kölker2015-10-18
|
* New puzzle from James Harvey: 'Tracks'.Simon Tatham2015-02-08
|
* New puzzle: 'Flood'.Simon Tatham2015-01-12
| | | | | | | | | | Based on a web game I saw a few years ago, and dashed off this weekend after I thought of a way to write a good (though not quite optimal) heuristic solver, here's a random little thing not quite in the same line as the most usual kind of Puzzles fare: instead of making you scratch your head to find any move to make at all, it's easy to find solutions in principle, and the challenge comes from having to do so within a move limit.
* Some more .gitignore updates.Simon Tatham2014-10-27
| | | | Ignore a few things that turn up in the icons subdirectory.
* Add a .gitignore, now this project is in git.Simon Tatham2014-10-25