mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-21 08:01:30 -07:00
84d3fd2bd8
Previously, the network, grid edges and barriers were all drawn with fixed line thickness of one pixel, or three pixels in the case of wires (one central one in a lit-up colour and a black border pixel on each side). This worked badly on high-DPI displays, or in any other environment where you expand the window noticeably. I've tried a few times before to fix this, but the problem was always that the Net drawing code was complicated and confusing, because Net was one of the founding puzzles in this collection and its drawing code predated a lot of the sensible organisation and best-practice doctrines I've come up with since then and used in the later puzzles. (The best example of this was the way that redrawing a grid square always redrew _all_ the surrounding borders, which is very confusing in the light of my later practice of dividing up the grid into disjoint regions that are always redrawn with clipping.) It was hard to make any change to the Net graphics with the code in that state; I tried several times and decided I couldn't sensibly make it work without throwing it all away and rewriting from scratch, which I was always reluctant to do. But not any more! Since Ian sent some patches to improve the graphics scaling in Tracks, and since Net was at the top of my personal wishlist of games that needed the same treatment, I've decided it's time to do just that. So, this commit throws out all of Net's previous redraw code, and replaces it with something in the more modern style I usually adopt in new puzzles. The new draw_tile() doesn't read data out of the game state willy-nilly; instead it takes a single word of bit-flags describing everything about the tile it's drawing, and makes all its decisions based on that word. And the main redraw loop constructs a whole array of flags words describing what it would _like_ the grid to look like, and then calls draw_tile() for every square whose word doesn't match the one that was previously drawn there. (With the one exception that the presence of the TILE_ROTATING flag in either the old or new word forces a redraw _even_ if the two words are identical, because that's how the move animation works.) The new graphics look more or less the same at the default resolution (there may be a pixel difference here or there but I don't think it's noticeable if so), but now they scale up properly if you enlarge or maximise the puzzle window.
This is the README accompanying the source code to Simon Tatham's puzzle collection. The collection's web site is at <https://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 git 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. Run 'nmake /f Makefile.vc' in a Visual Studio command prompt. - `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 <https://www.chiark.greenend.org.uk/~sgtatham/halibut/>.