mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-21 08:01:30 -07:00
c98230dedf
sensible means of generating an initial gridful of rectangles. This was previously a stupidly non-scalable bit of the Rectangles puzzle generator: it filled a ludicrously large array with every possible rectangle that could go anywhere in the grid, picked one at random and winnowed the list by removing anything that overlapped that one, then repeated until the list was empty (and therefore the grid was full except for remaining singleton squares). Total cost was O(N^4) in both time and space; not pretty. Richard and Chris's sensible alternative was to place each rectangle by randomly choosing a so-far-uncovered _square_, and then picking a random rectangle from the possible ones covering that square. This means we only have to deal with a small fragment of the rectangle list at any one time, and we don't have to store the whole lot in memory; so it's _much_ faster and more scalable, and has virtually no memory cost. A side effect of this algorithmic change is that the probability distribution has altered. When you line up all the possible _rectangles_ and pick one at random, then obviously the small ones are going to be in the majority since lots of small ones can fit into the space taken up by any given big one. So the original algorithm tends to favour fiddly grids full of lots of tiny rectangles, which don't tend to be very interesting. But if you first pick a square and then think about the rectangles that can surround that square, the small ones are suddenly going to be in the _minority_ because there are only two ways you can place (say) a 2x1 containing a given square compared to 36 ways you can place a 6x6. So this algorithm favours more large rectangles, which I generally consider to be an improvement. [originally from svn r5982]
This is the README accompanying the source code to Simon Tatham's puzzle collection. The collection's web site is at <http://www.chiark.greenend.org.uk/~sgtatham/puzzles/>. You should find several Makefiles in the source code: - `Makefile' should work under GNU make on Linux, provided you have GTK installed to compile and link against. It builds GTK binaries of the puzzle games. - `Makefile.vc' should work under MS Visual C++ on Windows. - `Makefile.cyg' should work under Cygwin / MinGW. With appropriate tweaks and setting of TOOLPATH, it should work for both compiling on Windows and cross-compiling on Unix. - `Makefile.osx' should work under Mac OS X, provided the Xcode tools are installed. It builds a single monolithic OS X application capable of running any of the puzzles, or even more than one of them at a time. Many of these Makefiles build a program called `nullgame' in addition to the actual game binaries. This program doesn't do anything; it's just a template for people to start from when adding a new game to the collection, and it's compiled every time to ensure that it _does_ compile and link successfully (because otherwise it wouldn't be much use as a template). Once it's built, you can run it if you really want to (but it's very boring), and then you should ignore it. DO NOT EDIT THE MAKEFILES DIRECTLY, if you plan to send any changes back to the maintainer. The makefiles are generated automatically by the Perl script `mkfiles.pl' from the file `Recipe'. If you need to change the makefiles as part of a patch, you should change Recipe and/or mkfiles.pl. The manual is provided in Windows Help format for the Windows build; in text format for anyone who needs it; and in HTML for the Mac OS X application and for the web site. It is generated from a Halibut source file (puzzles.but), which is the preferred form for modification. To generate the manual in other formats, rebuild it, or learn about Halibut, visit the Halibut website at <http://www.chiark.greenend.org.uk/~sgtatham/halibut/>.