aboutsummaryrefslogtreecommitdiff
path: root/map.c (follow)
Commit message (Collapse)AuthorAge
* Map: add missing sresize in new_game_desc().Simon Tatham2021-12-11
| | | | | | | | | | | Every time we append to the string 'ret', we check first that there's enough space, and realloc it larger if it's getting close to full. Except that I missed one case at the join between the two parts of the encoding. (Spotted because apparently on someone's build platform this led to a compiler warning that 'ret' might be null. I think _that's_ not a serious worry, but the missing resize was definitely unintentional.)
* Centralise initial clearing of the puzzle window.Simon Tatham2021-04-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't know how I've never thought of this before! Pretty much every game in this collection has to have a mechanism for noticing when game_redraw is called for the first time on a new drawstate, and if so, start by covering the whole window with a filled rectangle of the background colour. This is a pain for implementers, and also awkward because the drawstate often has to _work out_ its own pixel size (or else remember it from when its size method was called). The backends all do that so that the frontends don't have to guarantee anything about the initial window contents. But that's a silly tradeoff to begin with (there are way more backends than frontends, so this _adds_ work rather than saving it), and also, in this code base there's a standard way to handle things you don't want to have to do in every backend _or_ every frontend: do them just once in the midend! So now that rectangle-drawing operation happens in midend_redraw, and I've been able to remove it from almost every puzzle. (A couple of puzzles have other approaches: Slant didn't have a rectangle-draw because it handles even the game borders using its per-tile redraw function, and Untangle clears the whole window on every redraw _anyway_ because it would just be too confusing not to.) In some cases I've also been able to remove the 'started' flag from the drawstate. But in many cases that has to stay because it also triggers drawing of static display furniture other than the background.
* Add method for frontends to query the backend's cursor location.Franklin Wei2020-12-07
| | | | | | | | | | | | | | | | The Rockbox frontend allows games to be displayed in a "zoomed-in" state targets with small displays. Currently we use a modal interface -- a "viewing" mode in which the cursor keys are used to pan around the rendered bitmap; and an "interaction" mode that actually sends keys to the game. This commit adds a midend_get_cursor_location() function to allow the frontend to retrieve the backend's cursor location or other "region of interest" -- such as the player location in Cube or Inertia. With this information, the Rockbox frontend can now intelligently follow the cursor around in the zoomed-in state, eliminating the need for a modal interface.
* Add missing 'static' to game-internal declarations.Simon Tatham2018-11-13
| | | | | | | | | Another thing I spotted while trawling the whole source base was that a couple of games had omitted 'static' on a lot of their internal functions. Checking with nm, there turned out to be quite a few more than I'd spotted by eye, so this should fix them all. Also added one missing 'const', on the lookup table nbits[] in Tracks.
* Use C99 bool within source modules.Simon Tatham2018-11-13
| | | | | | | | | | This is the main bulk of this boolification work, but although it's making the largest actual change, it should also be the least disruptive to anyone interacting with this code base downstream of me, because it doesn't modify any interface between modules: all the inter-module APIs were updated one by one in the previous commits. This just cleans up the code within each individual source file to use bool in place of int where I think that makes things clearer.
* Replace TRUE/FALSE with C99 true/false throughout.Simon Tatham2018-11-13
| | | | | | This commit removes the old #defines of TRUE and FALSE from puzzles.h, and does a mechanical search-and-replace throughout the code to replace them with the C99 standard lowercase spellings.
* Adopt C99 bool in the game backend API.Simon Tatham2018-11-13
| | | | | | | | | | | encode_params, validate_params and new_desc now take a bool parameter; fetch_preset, can_format_as_text_now and timing_state all return bool; and the data fields is_timed, wants_statusbar and can_* are all bool. All of those were previously typed as int, but semantically boolean. This commit changes the API declarations in puzzles.h, updates all the games to match (including the unfinisheds), and updates the developer docs as well.
* Add a request_keys() function with a midend wrapper.Franklin Wei2018-04-22
| | | | | | | | This function gives the front end a way to find out what keys the back end requires; and as such it is mostly useful for ports without a keyboard. It is based on changes originally found in Chris Boyle's Android port, though some modifications were needed to make it more flexible.
* Map: stop storing pixel coordinates in game_ui.Simon Tatham2017-10-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Make the code base clean under -Wwrite-strings.Simon Tatham2017-10-01
| | | | | I've also added that warning option and -Werror to the build script, so that I'll find out if I break this property in future.
* Return error messages as 'const char *', not 'char *'.Simon Tatham2017-10-01
| | | | | They're never dynamically allocated, and are almost always string literals, so const is more appropriate.
* Use a proper union in struct config_item.Simon Tatham2017-10-01
| | | | | | This allows me to use different types for the mutable, dynamically allocated string value in a C_STRING control and the fixed constant list of option names in a C_CHOICES.
* New name UI_UPDATE for interpret_move's return "".Simon Tatham2017-10-01
| | | | | | | | | | | | | Now midend.c directly tests the returned pointer for equality to this value, instead of checking whether it's the empty string. A minor effect of this is that games may now return a dynamically allocated empty string from interpret_move() and treat it as just another legal move description. But I don't expect anyone to be perverse enough to actually do that! The main purpose is that it avoids returning a string literal from a function whose return type is a pointer to _non-const_ char, i.e. we are now one step closer to being able to make this code base clean under -Wwrite-strings.
* Rework the preset menu system to permit submenus.Simon Tatham2017-04-26
| | | | | | | | | | | | | | | | | | | | To do this, I've completely replaced the API between mid-end and front end, so any downstream front end maintainers will have to do some rewriting of their own (sorry). I've done the necessary work in all five of the front ends I keep in-tree here - Windows, GTK, OS X, Javascript/Emscripten, and Java/NestedVM - and I've done it in various different styles (as each front end found most convenient), so that should provide a variety of sample code to show downstreams how, if they should need it. I've left in the old puzzle back-end API function to return a flat list of presets, so for the moment, all the puzzle backends are unchanged apart from an extra null pointer appearing in their top-level game structure. In a future commit I'll actually use the new feature in a puzzle; perhaps in the further future it might make sense to migrate all the puzzles to the new API and stop providing back ends with two alternative ways of doing things, but this seemed like enough upheaval for one day.
* Giant const patch of doom: add a 'const' to every parameter in everySimon Tatham2013-04-13
| | | | | | | | | | | | | | puzzle backend function which ought to have it, and propagate those consts through to per-puzzle subroutines as needed. I've recently had to do that to a few specific parameters which were being misused by particular puzzles (r9657, r9830), which suggests that it's probably a good idea to do the whole lot pre-emptively before the next such problem shows up. [originally from svn r9832] [r9657 == 3b250baa02a7332510685948bf17576c397b8ceb] [r9830 == 0b93de904a98f119b1a95d3a53029f1ed4bfb9b3]
* Add 'const' to the game_params arguments in validate_desc andSimon Tatham2013-04-12
| | | | | | | | | | | | new_desc. Oddities in the 'make test' output brought to my attention that a few puzzles have been modifying their input game_params for various reasons; they shouldn't do that, because that's the game_params held permanently by the midend and it will affect subsequent game generations if they modify it. So now those arguments are const, and all the games which previously modified their game_params now take a copy and modify that instead. [originally from svn r9830]
* New rule: interpret_move() is passed a pointer to the game_drawstateSimon Tatham2012-09-09
| | | | | | | | | | | | | | | | basically just so that it can divide mouse coordinates by the tile size, but is definitely not expected to _write_ to it, and it hadn't previously occurred to me that anyone might try. Therefore, interpret_move() now gets a pointer to a _const_ game_drawstate instead of a writable one. All existing puzzles cope fine with this API change (as long as the new const qualifier is also added to a couple of subfunctions to which interpret_move delegates work), except for the just-committed Undead, which somehow had ds->ascii and ui->ascii the wrong way round but is otherwise unproblematic. [originally from svn r9657]
* Changed my mind about midend_is_solved: I've now reprototyped it asSimon Tatham2011-06-19
| | | | | | | | | | | | | | | | midend_status(), and given it three return codes for win, (permanent) loss and game-still-in-play. Depending on what the front end wants to use it for, it may find any or all of these three states worth distinguishing from each other. (I suppose a further enhancement might be to add _non_-permanent loss as a fourth distinct status, to describe situations in which you can't play further without pressing Undo but doing so is not completely pointless. That might reasonably include dead-end situations in Same Game and Pegs, and blown-self-up situations in Mines and Inertia. However, I haven't done this at present.) [originally from svn r9179]
* Add a function to every game backend which indicates whether a gameSimon Tatham2011-04-02
| | | | | | | | | | | state is in a solved position, and a midend function wrapping it. (Or, at least, a situation in which further play is pointless. The point is, given that game state, would it be a good idea for a front end that does that sort of thing to proactively provide the option to start a fresh game?) [originally from svn r9140]
* Memory management and other fixes from James H.Simon Tatham2009-06-17
| | | | [originally from svn r8596]
* Keyboard control for Map, from James H.Simon Tatham2009-01-27
| | | | [originally from svn r8434]
* New infrastructure feature. Games are now permitted to beSimon Tatham2008-09-06
| | | | | | | | | | | | | | | | | | | | | | _conditionally_ able to format the current puzzle as text to be sent to the clipboard. For instance, if a game were to support playing on a square grid and on other kinds of grid such as hexagonal, then it might reasonably feel that only the former could be sensibly rendered in ASCII art; so it can now arrange for the "Copy" menu item to be greyed out depending on the game_params. To do this I've introduced a new backend function (can_format_as_text_now()), and renamed the existing static backend field "can_format_as_text" to "can_format_as_text_ever". The latter will cause compile errors for anyone maintaining a third-party front end; if any such person is reading this, I apologise to them for the inconvenience, but I did do it deliberately so that they'd know to update their front end. As yet, no checked-in game actually uses this feature; all current games can still either copy always or copy never. [originally from svn r8161]
* Revise the printing colour framework so that we can explicitlySimon Tatham2008-04-07
| | | | | | | request either of hatching or halftoning, and also choose which to supply as a fallback when printing in colour. [originally from svn r7976]
* General cleanups patch from James H:Simon Tatham2007-02-28
| | | | | | | | | | | | - missing static in filling.c - better robustness in execute_move() in filling.c - remove side effects in assert statements - remove rogue diagnostic in galaxies.c - remove // comment in map.c - add more stylus-friendly UI to Pattern - bias Unequal towards generating inequality clues rather than numeric [originally from svn r7344]
* Dariusz Olszewski's changes to support compiling for PocketPC. ThisSimon Tatham2007-02-26
| | | | | | | | | | | | is mostly done with ifdefs in windows.c; so mkfiles.pl generates a new makefile (Makefile.wce) and Recipe enables it, but it's hardly any different from Makefile.vc apart from a few definitions at the top of the files. Currently the PocketPC build is not enabled in the build script, but with any luck I'll be able to do so reasonably soon. [originally from svn r7337]
* HTML Help support for Puzzles, with the same kind of automaticSimon Tatham2006-12-24
| | | | | | fallback behaviour as PuTTY's support. [originally from svn r7009]
* Mike's changes to dsf.c alter the internal storage format of dsfSimon Tatham2006-11-01
| | | | | | | | | structures, meaning that ad-hoc initialisation now doesn't work. Hence, this checkin converts all ad-hoc dsf initialisations into calls to dsf_init() or snew_dsf(). At least, I _hope_ I've caught all of them. [originally from svn r6888]
* Cleanup: it was absolutely stupid for game_wants_statusbar() to be aSimon Tatham2005-10-22
| | | | | | | | | function, since it took no parameters by which to vary its decision, and in any case it's hard to imagine a game which only _conditionally_ wants a status bar. Changed it into a boolean data field in the backend structure. [originally from svn r6417]
* Cleanup: remove the game_state parameter to game_colours(). No gameSimon Tatham2005-10-22
| | | | | | | | | | | | was actually using it, and also it wasn't being called again for different game states or different game parameters, so it would have been a mistake to depend on anything in that game state. Games are now expected to commit in advance to a single fixed list of all the colours they will ever need, which was the case in practice already and simplifies any later port to a colour-poor platform. Also this change has removed a lot of unnecessary faff from midend_colours(). [originally from svn r6416]
* Cleanup: the `mouse_priorities' field in the back end has been aSimon Tatham2005-10-22
| | | | | | | more general-purpose flags word for some time now. Rename it to `flags'. [originally from svn r6414]
* Cleanup: rename random_init() to random_new(), because it actuallySimon Tatham2005-10-22
| | | | | | | _allocates_ a random_state rather than just initialising one passed in by the caller. [originally from svn r6412]
* Use game_set_size() to set up the temporary drawstate inSimon Tatham2005-09-23
| | | | | | | | | | | | | | | | | | game_print(), wherever feasible. This fixes a specific bug in Loopy (James H's new field ds->linewidth wasn't being set up, leading to corrupted print output), but I've made the change in all affected files because it also seems like a generally good idea to encourage it for future games, to prevent other problems of this type. There is one slight snag, which is that Map _can't_ do this because its game_set_size() also initialises a blitter. I could fix this by abstracting the common parts of Map's game_set_size() out into a subfunction called by game_set_size() and also called directly by game_print(); alternatively, I could introduce a means of determining whether a `drawing *' was for screen or printing use. Not sure which yet. [originally from svn r6340]
* Various patches from Ben H: a fix for an outdated comment, a coupleSimon Tatham2005-09-05
| | | | | | | of spurious ps_printf() arguments removed, and an error check in the `make install' target. [originally from svn r6275]
* I've dithered a bit in the past about whether or not it's allowableSimon Tatham2005-09-05
| | | | | | | | | | to call game_set_size() twice on the same drawstate. Finally, a definite decision: it isn't. Accordingly, midend.c arranges never to do so, the devel docs state that puzzles may enforce by assertion that it never happens, and the four puzzles which care (i.e. use blitters) do so. [originally from svn r6274]
* Patches from James H. The usual stuff (memory leak fixes and 16-bitSimon Tatham2005-09-03
| | | | | | | | | cleanliness), plus he's enlarged the pencil-mark circles from TILESIZE/8 to TILESIZE/7. Makes no difference at all (thanks to integer division) when TILESIZE is the default of 20, but presumably helps at some other tile sizes. Fine by me. [originally from svn r6265]
* James H has implemented a new `Tricky' difficulty level in Light Up:Simon Tatham2005-09-01
| | | | | | | | | | | | | | | | | | a non-recursive level above Easy, which therefore moves the recursive Hard mode further up still. Play-testing suggests that in fact Tricky is often _harder_ than the old Hard mode, since the latter had limited depth of recursion and would therefore spot complex deductions only if it happened to start a recursion on the right square; Tricky may be limited in the sophistication of its complex deductions, but it never misses one, so its puzzles tend to be hard all over. Also in this checkin, a new source file `nullfe.c', containing all the annoying stub functions required to make command-line solvers link successfully. James wrote this for (the new) lightupsolver, and I've used it to simplify the other stand-alone solvers. [originally from svn r6254]
* Ability to drag pencil marks around.Simon Tatham2005-08-31
| | | | [originally from svn r6250]
* Terribly cunning approach to making the pencil marks look nicer,Simon Tatham2005-08-31
| | | | | | thanks to Gareth. [originally from svn r6248]
* Ahem; forgot about recursion. Recursive solving now shows itsSimon Tatham2005-08-31
| | | | | | working as well. [originally from svn r6245]
* Now that Map has some seriously complex deductions, it's about timeSimon Tatham2005-08-31
| | | | | | | | | | | | it had a command-line solver. In order to do this, I've had to expose the internal region numbering because the solver has to have some way to state which region it means; and in any case it's also useful to have human-visible region numbering so that two people can discuss a puzzle they're solving together. So pressing L during play now toggles the display of region numbers; and `mapsolver' uses those same numbers when showing its working and its solutions. [originally from svn r6244]
* Forcing chains in Map give rise to a new `Hard' difficulty level.Simon Tatham2005-08-30
| | | | | | | Also implemented the Map analogue of Solo's pencil marks, to make this mode more playable. [originally from svn r6240]
* Typo in comment :-)Simon Tatham2005-08-29
| | | | [originally from svn r6236]
* Ahem. The region density at which things start to get hairy is 2/3Simon Tatham2005-08-29
| | | | | | of the grid area, not 3/2! [originally from svn r6235]
* Aesthetic improvements to the Map error indicators:Simon Tatham2005-08-29
| | | | | | | | | - the exclamation mark was a bit dot-heavy - allowing the indicator to be placed at a grid point as well as half way between two grid points allows some much more natural positioning. [originally from svn r6234]
* Unreasonable mode for Map.Simon Tatham2005-08-28
| | | | [originally from svn r6229]
* Error highlighting in Map.Simon Tatham2005-08-28
| | | | [originally from svn r6228]
* `Solve' operation on an already solved map without an aux_info wasSimon Tatham2005-08-22
| | | | | | | returning NULL due to no moves being required, leading to a strange error message. Trivial fix. [originally from svn r6198]
* Substantial infrastructure upheaval. I've separated the drawing APISimon Tatham2005-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as seen by the back ends from the one implemented by the front end, and shoved a piece of middleware (drawing.c) in between to permit interchange of multiple kinds of the latter. I've also added a number of functions to the drawing API to permit printing as well as on-screen drawing, and retired print.py in favour of integrated printing done by means of that API. The immediate visible change is that print.py is dead, and each puzzle now does its own printing: where you would previously have typed `print.py solo 2x3', you now type `solo --print 2x3' and it should work in much the same way. Advantages of the new mechanism available right now: - Map is now printable, because the new print function can make use of the output from the existing game ID decoder rather than me having to replicate all those fiddly algorithms in Python. - the new print functions can cope with non-initial game states, which means each puzzle supporting --print also supports --with-solutions. - there's also a --scale option permitting users to adjust the size of the printed puzzles. Advantages which will be available at some point: - the new API should permit me to implement native printing mechanisms on Windows and OS X. [originally from svn r6190]
* Memory leak fixes from James H.Simon Tatham2005-08-13
| | | | [originally from svn r6188]
* New puzzle: `Map'. Vaguely original, for a change.Simon Tatham2005-08-13
(This puzzle is theoretically printable, but I haven't added it in print.py since there's rather a lot of painful processing required to get from the game ID to the puzzle's visual appearance. It probably won't become printable unless I get round to implementing a more integrated printing architecture.) [originally from svn r6186]
generated by cgit v1.1 at 2026-04-25 02:03:18 +0000