mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-21 08:01:30 -07:00
b33b83429f
Jonas Kölker points out that commit a800ff16b (which fixed a bug in the previous attempt) left in another bug: if the puzzle size was changed while the window was maximised, the system would fail to recompute the tile size and would redraw completely wrongly. So it's not optional after all to run midend_size(), even if the drawing area size hasn't changed. I've reverted that code to be unconditional, and now only the refresh of the Cairo-side backing store system is conditionalised - and that's conditionalised on changes to either the size of the actual window _or_ the size of the contained pixmap. (The latter should defend against redraw failure in the case where the puzzle aspect ratio changes, so that neither the window size nor the tile size changes but a recentre is still needed.) I _think_ this now fixes all the cases of resizing: this time I've tested making an unmaximised puzzle window bigger or smaller, and within a maximised window, forcing the puzzle to scale up, scale down, or change its aspect ratio without changing its tile size. All work, on GTK2 and GTK3, and yet we still don't get the visible flicker on status line updates that was the reason I started fiddling with this code in the first place. (We _do_ still call configure_area on every update of the status line, at least under GTK3; that's going to cause a forced full redraw on every timer tick in Mines, which is wasteful of CPU, so it would still be nice to find a better way of identifying the cases in which no resizing at all was necessary and we could avoid renewing the game drawstate. But the current code at least doesn't have any display _errors_ that I know of, which is an improvement on its previous state.)
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/>. If you've obtained the source code by downloading a .tar.gz archive from the Puzzles web site, you should find several Makefiles in the source code. However, if you've checked the source code out from the Puzzles Subversion repository, you won't find the Makefiles: they're automatically generated by `mkfiles.pl', so run that to create them. The Makefiles include: - `Makefile.am', together with the static `configure.ac', is intended as input to automake. Run `mkauto.sh' to turn these into a configure script and Makefile.in, after which you can then run `./configure' to create an actual Unix Makefile. - `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. - `Makefile.wce' should work under MS eMbedded Visual C++ on Windows and the Pocket PC SDK; it builds Pocket PC binaries. 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' and the various .R files. If you need to change the makefiles as part of a patch, you should change Recipe, *.R, 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/>.