mirror of
git://git.tartarus.org/simon/puzzles.git
synced 2025-04-20 23:51:29 -07:00
6da8dc91a2
The fields (ui->dragx,ui->dragy) stored the pixel coordinates of the visible cursor (if any), no matter whether that cursor was being displayed in response to a mouse dragging action or arrow-key activity. But this meant that resizing the window while the keyboard cursor was visible would cause the cursor to be drawn in totally the wrong place in the newly resized window: you get a new drawstate with a fresh blitter (so at least no part of the old-size window is accidentally 'restored' on to the new-size one), but the ui fields saying where _next_ to draw the cursor would still have bogus values left over from the previous window size. To fix this, I've arranged that we simply don't use ui->dragx and ui->dragy any more in keyboard cursor mode: instead, we leave it to game_redraw to spot that the keyboard cursor is visible and compute its pixel coordinates for display. A knock-on effect is that when we need to know which region is under the cursor during interpret_move, we can't use the previous strategy of just calling region_from_coords(ui->dragx, ui->dragy) regardless of which kind of cursor is active. So I've split that function up into an inner section taking a tile and a displacement from the tile's centre and an outer part which derives those from real pixel coordinates in the case where the cursor is originating from a mouse drag; then there's a new alternative outer part which derives the same (tile, displacement) pair purely from the game_ui keyboard cursor data without having to explicitly translate into pixels and back in the middle. Probably a less fragile strategy anyway.
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/>.