aboutsummaryrefslogtreecommitdiff
path: root/rect.c (follow)
Commit message (Collapse)AuthorAge
* Introduce ftoa() as a replacement for the %g format specifierFranklin Wei2020-12-07
| | | | | Not all platforms support printing floats, this is a more portable (if uglier) way.
* 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.
* 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.
* 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.
* Rename the docs section for Rectangles.Simon Tatham2016-01-07
| | | | | | | | | The web page currently assumes it's called 'rect' rather than 'rectangles', because the web-page building script uses the first field of each line of gamedesc.txt, same as the Unix binary name. Rather than add another confusingly-almost-identical field to that file, it's easier to just rename this one docs section to make the assumption of equality hold.
* rect: Fix compiler errors about uninitialized use of variablesKhem Raj2015-12-31
| | | | | | | | | | | | | | error: 'r2.x' may be used uninitialized in this function Its happening when using gcc 5.3 with musl C library. its considering the case when case falls into default and immediately after exiting this there is a check if (r1.h > 0 && r1.w > 0) where r1 element is used but not assigned anything. GCC is not noticing the control flow where the initilization will always work due to assertion call can be a function call from libc Signed-off-by: Khem Raj <raj.khem@gmail.com>
* Rectangles: cancel keyboard drag with Escape.Jonas Kölker2015-10-03
|
* 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]
* Sort out a bit of confusion between mouse- and keyboard-driven dragsSimon Tatham2012-01-31
| | | | | | | | | | | in Rectangles. Mouse drags now take priority - you can't start a keyboard drag while the mouse is held down, and starting a mouse drag instantly cancels an unfinished keyboard drag - and also I've fixed an assertion failure which would come up if you had the keyboard cursor visible at the end of a mouse drag (by pressing arrow keys while the mouse was held down). [originally from svn r9393]
* 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]
* Single mouse clicks to toggle individual grid edges stopped workingSimon Tatham2009-10-13
| | | | | | | | in r8414 as a side effect of reorganisation in interpret_move(). Reinstate them. [originally from svn r8692] [r8414 == 54801998744a69786a49ebe0688942ae7b57525b]
* Keyboard cursor support for Rectangles, from James H.Simon Tatham2009-01-15
| | | | [originally from svn r8414]
* 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]
* Er, and now do that _without_ introducing further segfaults.Simon Tatham2007-03-26
| | | | [originally from svn r7409]
* Stop failing assertions when we encounter an insoluble puzzle.Simon Tatham2007-03-26
| | | | [originally from svn r7408]
* 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]
* 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]
* 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]
* 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]
* Ben Hutchings reports that gcc 4 gives an optimiser warning becauseSimon Tatham2005-07-29
| | | | | | | | it can't tell that one branch of a particular switch is always taken. Adding a default clause with an automatic assertion failure apparently fixes it. [originally from svn r6148]
* Fix to Chris's patch in r6106 (also from Chris).Simon Tatham2005-07-18
| | | | | [originally from svn r6117] [r6106 == a31934f233581da07153af6b4ee717f1e63387dd]
* Patch from Chris Emerson: rather than dynamically callingSimon Tatham2005-07-17
| | | | | | | get_correct() at (among other things) every redraw, we call it once at the creation of a new game_state to save CPU. [originally from svn r6106]
* game_timing_state() now has access to the game_ui. This means thatSimon Tatham2005-07-10
| | | | | | | | | | | | whether the timer is currently going is no longer solely dependent on the current game_state: it can be dependent on more persistent information stored in the game_ui. In particular, Mines now freezes the timer permanently once you complete a grid for the first time, so that you can then backtrack through your solution process without destroying the information about how long it took you the first time through. [originally from svn r6088]
* Add a `full' parameter to validate_params(), analogous to the one inJacob Nevins2005-07-05
| | | | | | | | | | | encode_params(). This is necessary for cases where generation-time parameters that are normally omitted from descriptive IDs can place restrictions on other parameters; in particular, when the default value of a relevant generation-time parameter is not the one used to generate the descriptive ID, validation could reject self-generated IDs (e.g., Net `5x2w:56182ae7c2', and some cases in `Pegs'). [originally from svn r6068]
* Refactored the game_size() interface, which was getting reallySimon Tatham2005-07-05
| | | | | | | | | | | | | unpleasant and requiring lots of special cases to be taken care of by every single game. The new interface exposes an integer `tile size' or `scale' parameter to the midend and provides two much simpler routines: one which computes the pixel window size given a game_params and a tile size, and one which is given a tile size and must set up a drawstate appropriately. All the rest of the complexity is handled in the midend, mostly by binary search, so grubby special cases only have to be dealt with once. [originally from svn r6059]
* Prevent drags from being started outside the playing area, which wasSimon Tatham2005-06-30
| | | | | | | | causing invalid move descriptions to be returned from interpret_move() and then failing an assertion when execute_move() refused them. [originally from svn r6044]
* General robustness patch from James Harvey:Simon Tatham2005-06-30
| | | | | | | | | | | | | - most game_size() functions now work in doubles internally and round to nearest, meaning that they have less tendency to try to alter a size they returned happily from a previous call - couple of fiddly fixes (memory leaks, precautionary casts in printf argument lists) - midend_deserialise() now constructs an appropriate drawstate, which I can't think how I overlooked myself since I _thought_ I went through the entire midend structure field by field! [originally from svn r6041]
* New {en,de}code_ui functions should be static. Oops.Simon Tatham2005-06-28
| | | | [originally from svn r6031]
* More serialisation changes: the game_aux_info structure has now beenSimon Tatham2005-06-28
| | | | | | | | | | | | retired, and replaced with a simple string. Most of the games which use it simply encode the string in the same way that the Solve move will also be encoded, i.e. solve_game() simply returns dupstr(aux_info). Again, this is a better approach than writing separate game_aux_info serialise/deserialise functions because doing it this way is self-testing (the strings are created and parsed during the course of any Solve operation at all). [originally from svn r6029]
* Another function pair required for serialisation; these ones saveSimon Tatham2005-06-28
| | | | | | | | | | | and restore anything vitally important in the game_ui. Most of the game_ui is expected to be stuff about cursor positions and currently active mouse drags, so it absolutely _doesn't_ want to be preserved over a serialisation; but one or two things would be disorienting or outright wrong to reset, such as the Net origin position and the Mines death counter. [originally from svn r6026]
* Re-architecting of the game backend interface. make_move() has beenSimon Tatham2005-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | split into two functions. The first, interpret_move(), takes all the arguments that make_move() used to get and may have the usual side effects of modifying the game_ui, but instead of returning a modified game_state it instead returns a string description of the move to be made. This string description is then passed to a second function, execute_move(), together with an input game_state, which is responsible for actually producing the new state. (solve_game() also returns a string to be passed to execute_move().) The point of this is to work towards being able to serialise the whole of a game midend into a byte stream such as a disk file, which will eventually support save and load functions in the desktop puzzles, as well as restoring half-finished games after a quit and restart in James Harvey's Palm port. Making each game supply a convert-to-string function for its game_state format would have been an unreliable way to do this, since those functions would not have been used in normal play, so they'd only have been tested when you actually tried to save and load - a recipe for latent bugs if ever I heard one. This way, you won't even be able to _make_ a move if execute_move() doesn't work properly, which means that if you can play a game at all I can have pretty high confidence that serialising it will work first time. This is only the groundwork; there will be more checkins to come on this theme. But the major upheaval should now be done, and as far as I can tell everything's still working normally. [originally from svn r6024]
* Patch from James Harvey in response to the new Rectangles gridSimon Tatham2005-06-21
| | | | | | | | | generator: (a) take out the `#ifdef SLOW_SYSTEM' because the new generator is much more efficient, and (b) convert another int to size_t to prevent the solver going negative in 16-bit ints as a result. [originally from svn r5983]
* Conversation with Richard and Chris yesterday gave rise to a moreSimon Tatham2005-06-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* Infrastructure change which I've been thinking about for a while:Simon Tatham2005-06-17
| | | | | | | the back end function solve_game() now takes the _current_ game_state in addition to the initial one. [originally from svn r5969]
* Clean up the behaviour of drags off the edge of the grid. These haveSimon Tatham2005-06-10
| | | | | | | always been a convenient way to cancel a drag you decided was an error, but now it's more obvious that this is the case. [originally from svn r5941]
* Patch from Chris Emerson to add a status bar to Rectangles. ApartSimon Tatham2005-06-10
| | | | | | | | | from saying `Auto-solved' or `Completed', the main function of the status bar is to track the current size of a rectangle you're dragging out, which makes life much easier when trying to count up large rectangles in 19x19 mode. [originally from svn r5937]
* Integer overflow in game_size(). Oops.Simon Tatham2005-06-07
| | | | [originally from svn r5921]
* All the games in this collection have always defined their graphicsSimon Tatham2005-06-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | in terms of a constant TILE_SIZE (or equivalent). Here's a surprisingly small patch which switches this constant into a run-time variable. The only observable behaviour change should be on Windows, which physically does not permit the creation of windows larger than the screen; if you try to create a puzzle (Net makes this plausible) large enough to encounter this restriction, the Windows front end should automatically re-adjust the puzzle's tile size so that it does fit within the available space. On GTK, I haven't done this, on the grounds that X _does_ permit windows larger than the screen, and many X window managers already provide the means to navigate around such a window. Gareth said he'd rather navigate around a huge Net window than have it shrunk to fit on one screen. I'm uncertain that this makes sense for all puzzles - Pattern in particular strikes me as something that might be better off shrunk to fit - so I may have to change policy later or make it configurable. On OS X, I also haven't done automatic shrinkage to fit on one screen, largely because I didn't have the courage to address the question of multiple monitors and what that means for the entire concept :-) [originally from svn r5913]
generated by cgit v1.1 at 2026-04-26 08:14:17 +0000