aboutsummaryrefslogtreecommitdiff
path: root/midend.c (follow)
Commit message (Collapse)AuthorAge
* End victory flash on new game and restart game.Jonas Kölker2015-10-14
| | | | | | | | | | | | Net provides the best demonstration of why. Complete a game of net, then press N while the victory flash is playing: then the victory flash keeps playing on the new game board. (Tip: save a game which but for a redo is completed, then you can reproduce this repeatedly without having to complete a new game each time.) The flash timer reset code is placed together with the animation timer reset code, because the two are conceptually related. Note that midend_restart_game resets animations via midend_finish_move.
* Reset midend animation counters on starting a new game.Jonas Kölker2015-10-14
| | | | | | This is already done in midend_restart_game via midend_finish_move. If it's good enough for restarting a game, it ought to also be good enough for starting new games.
* Remove a redundant line of code.Jonas Kölker2015-10-14
| | | | | Setting me->anim_time = 0.0 right before calling midend_finish_move is redundant, since midend_finish_move itself sets me->anim_time = 0.
* Don't stop animations when restarting an already restarted game.Jonas Kölker2015-10-14
| | | | | | | | Restarting a game that is already in the restarted state is meant to be a no-op. It stopped animations. Don't do this. Also, given that midmidend_restart_game called midend_stop_anim twice, the invocation we remove was redundant.
* Stop animations on a new game, no matter how it is started.Jonas Kölker2015-10-14
| | | | | | | | Animations were stopped if a new game was initiated with a keyboard shortcut (n, N, Ctrl-N), but not via menu items such as presets or custom configurations, nor (perhaps not a problem) on starting the program. Fix this, so that animations are stopped on a new game no matter how the new game is started.
* Fix typo in undo key handling.Jonas Kölker2015-10-03
| | | | | Now we can undo with both 'u' and 'U', symmetrically with redoing with both 'r' and 'R'.
* Change the policy for parsing underspecified params strings.Simon Tatham2014-11-29
| | | | | | | | | | | | | | | | | | | In conversation with a user last week, it emerged that the command 'solo --generate 1 9jk#12345' was giving a different game from the one it gave when I ran it, and it turns out that this is because I've set SOLO_DEFAULT=7jxdi in my environment to make GUI Solo automatically start up in my (current) favourite mode. And the difficulty setting from that parameter string was being reused to fill in the unspecified difficulty slot in the '9jk', so that the same params string was being interpreted differently by our two machines. This is certainly wrong - the whole point of random seed strings like that is to be interpreted the same way everywhere. But it's a side effect of something I did do on purpose, for people switching back and forth between playing randomly generated games and playing a game id pasted (or typed) in from elsewhere. So this fix, with a giant comment explaining it, I _think_ should retain the behaviour I originally wanted while getting rid of the behaviour I didn't.
* Introduce some extra testing and benchmarking command-line options toSimon Tatham2013-04-11
| | | | | | | | | | | | | | | | the GTK front end, plus a 'make test' target in the GTK makefile which uses them to automatically generate 100 puzzles for each game at each preset configuration, test-run them back through the solver without their aux_info to ensure that can cope, and produce an HTML box plot of game generation times for each preset. As part of this work I've removed the TESTSOLVE mechanism from r9549, since the new --test-solve option does the same thing better (in that when something goes wrong it prints the random seed that caused the problem). [originally from svn r9825] [r9549 == 5a095b8a08fa9f087b93c86aea0fa027138b028d]
* Add a new midend function to reset the tile size to the puzzle'sSimon Tatham2013-04-07
| | | | | | | default (but still counting the <puzzle>_TILESIZE user preference environment variables, where available). [originally from svn r9820]
* Don't forget to NULL out the new game id notification callback, orSimon Tatham2013-04-06
| | | | | | | else it might start off accidentally initialised to nonsense in front ends which don't use it. [originally from svn r9817]
* I've just realised that the JS puzzles' permalinks were not updatingSimon Tatham2013-04-05
| | | | | | | | | | | | | | | when the user pressed 'n' for a new game, because all the front end knows is that it passed a keystroke to the puzzle, and it has no way of hearing back that a particular keypress resulted in a game id change. To fix this, I've renamed midend_request_desc_changes to midend_request_id_changes and expanded its remit to cover _any_ change to the game ids. So now that callback in the Emscripten front end is the only place from which update_permalinks is called (apart from initialising them at setup time), and that should handle everything. [originally from svn r9805]
* Introduce a mechanism by which calls to midend_supersede_game_desc()Simon Tatham2013-03-31
| | | | | | | can trigger a call to a front end notification function. Use this to update the game ID permalink when Mines supersedes its game ID. [originally from svn r9793]
* Add a midend function to return the current random seed, parallel toSimon Tatham2013-03-30
| | | | | | | the existing one that returns the game id. No front end has so far needed this, but one is about to. [originally from svn r9778]
* Revamp of the Windows command-line parsing and puzzle-loading code.Simon Tatham2013-01-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows puzzles now accept similar command-line syntax to the GTK ones, in that you can give them either a game ID (descriptive, random or just plain params) or the name of a save file. Unlike the GTK ones, however, the save file interpretation is tried first; this is because some puzzles (e.g. Black Box) will interpret any old string as a valid (if boring) game ID, and unlike the GTK puzzles it's not feasible to require users to disambiguate via a command-line option, because on Windows a thing that might easily happen is that a user passes a save file to a puzzle binary via 'Open With' in the GUI shell, where they don't get the chance to add extra options. In order to make this work sensibly in the all-in-one Windows app, I had to get round to another thing I've been planning to do for a while, which is to write a function to examine a saved game file and find out which puzzle it's for. So the combined Windows binary will auto-switch to the right game if you pass a save file on its command line, and also if you use Load while the program is running. Another utility function I needed is one to split the WinMain single command line string into argv. For this I've imported a copy of split_into_argv() from Windows PuTTY (which doesn't affect this package's list of copyright holders, since that function was all my own code anyway). [originally from svn r9749]
* Add a hacky environment variable that lets me arrange a soak-test of aSimon Tatham2012-06-01
| | | | | | | | | | | | solver I've just modified, by forcing every game generation to be instantly followed by an attempt to re-solve the same game _description_ without the aux_info. I've hacked similar changes in to midend.c several times in the last couple of months for one reason or another, and it's about time I arranged not to have to recompile to do it! [originally from svn r9549]
* Permit users to reconfigure the default setting for each puzzle usingSimon Tatham2012-04-10
| | | | | | another of those hacky environment variables. [originally from svn r9455]
* Allow --save to work with --soln, causing saved game files to beSimon Tatham2011-12-28
| | | | | | written out with the Solve operation having already been performed. [originally from svn r9375]
* 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]
* Add functions provided by the midend to tell a front end whether GUISimon Tatham2011-04-02
| | | | | | buttons for undo and redo should currently be greyed out. [originally from svn r9139]
* Memory leak fix from Tiago Dionizio: whenever we free the midend'sSimon Tatham2010-01-04
| | | | | | | collection of game states, we should also free the move strings from which they were constructed. [originally from svn r8805]
* Jonas Koelker points out that the backspace key didn't work in GTKSimon Tatham2009-12-20
| | | | | | | | | | Guess, because Guess expected ^H whereas GTK generated ^?. Other puzzles that use Backspace do it by being prepared to see either, which seems wasteful. Now the midend normalises both into ^H, so front ends can generate whichever they like while puzzles can safely just look for ^H. [originally from svn r8786]
* Memory management and other fixes from James H.Simon Tatham2009-06-17
| | | | [originally from svn r8596]
* Patch from James H to enable a single monolithic binary to be builtSimon Tatham2009-01-06
| | | | | | | | alongside the individual puzzle binaries, on Windows only. (MacOS already has it, of course; Unix would require about as much work again.) [originally from svn r8396]
* Couple of solving-related mid-end tweaks. Firstly, when we generateSimon Tatham2008-11-16
| | | | | | | | | | | | | | | | | | a game which comes with an aux string, we immediately self-test that string by passing it to solve() and test by assertion that it succeeded. So a bug in a back end which intermittently generates malformed aux strings will be detected as soon as it occurs, instead of only if the user happens to use the Solve operation on a particular game in which it happened. Secondly, Ctrl-S now (undocumentedly) triggers the Solve operation, on the general principle that keyboard shortcuts tend to come in handy, and on the specific principle that if you want to look at lots of solved grids in quick succession (say, when observing their general shape and nature to see if your generation algorithm was good or not) it's handy to have a quick way of getting to them. [originally from svn r8298]
* Patch from James H providing lots more paranoid casting. Also oneSimon Tatham2008-09-13
| | | | | | | | | | actual behaviour change: Untangle now permits dragging with the right mouse button, which has exactly the same effect as it does with the left. (Harmless on desktop platforms, but helpful when "right-click" is achieved by press-and-hold; now the drag takes place even if you hesitate first.) [originally from svn r8177]
* Patch from James H to centralise some generally useful cursor-Simon Tatham2008-09-13
| | | | | | handling functionality into misc.c. [originally from svn r8176]
* 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]
* New feature in midend.c which allows us to ask for the number of theSimon Tatham2008-04-08
| | | | | | | | | | currently selected preset, if any. I've used this in the GTK front end to have the Type menu mark the currently selected menu item. (After considerable beating of GTK with sticks, I might add. Grr.) Currently the same UI feature is not yet supported on Windows or MacOS, but I hope to do those too at some point if it's feasible. [originally from svn r7980]
* Since we've changed the semantics of the `expand' argument to midend_size(),Jacob Nevins2007-03-03
| | | | | | change the name. Also document the new semantics. [originally from svn r7369]
* Patch from Ben Hutchings to allow user-initiated tilesize changes to persistJacob Nevins2007-03-03
| | | | | | | | across changes in game parameters (e.g., changing difficulty without changing size). This also has the effect of preserving the user-selected tilesize if the grid size is changed. (From Debian bug#379452.) [originally from svn r7368]
* New mechanism for automatic generation of the puzzle screenshots onSimon Tatham2006-12-26
| | | | | | | | | | | | | | | | | | | the web, which I hope will also end up being extended to generate both Windows and X icons for each individual puzzle. The mechanism is: for each puzzle there's a save file in the `icons' subdirectory showing a game state which I think is a decent illustration of the puzzle, and then there's a nasty set of scripts which runs each puzzle binary, loads that save file, grabs a screenshot using xwd, and munges it into shape. In order to support this I've added two new options (--redo and --windowid) to all the GTK puzzles, which I don't expect ever to be used outside the icons makefile. I've also added two more options (--load and --id) which force a GTK puzzle to treat its command-line option as a save file or as a game ID respectively (the previous behaviour was always to guess, and sometimes it guessed wrong). [originally from svn r7014]
* Patch I've had lurking around for over a year and not remembered toSimon Tatham2006-11-20
| | | | | | | | | | | | | commit: arrange that midend_set_timer(), hence game_timing_state(), is called when the game_ui is changed. This allows timed games to work by obscuring the initial layout until an initial click causes it to be revealed, without requiring that they store that reveal operation as a move in the undo chain. Not that any games actually do this, but it's clearly a sensible thing to want to do: since game_timing_state() _receives_ a game_ui as a parameter, obviously it should be consulted when the game_ui changes. [originally from svn r6914]
* Cleanup: relieve frontends of the duty to callSimon Tatham2005-10-22
| | | | | | | | | | | | | midend_rewrite_statusbar() and check the result against the last string returned. This is now done centrally in drawing.c, and the front end status bar function need only do what it says on the tin. While I'm modifying the prototype of drawing_init(), I've also renamed it drawing_new() for the same reason as random_new() (it _allocates_ a drawing object, rather than just initialising one passed in). [originally from svn r6420]
* 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]
* I found a slightly odd-looking line of code in this file a few daysSimon Tatham2005-09-12
| | | | | | | | ago, and nearly changed it to the obvious thing. After some thought, though, I've decided the `bug' is better off unfixed, and added a comment explaining why. [originally from svn r6293]
* Marginally greater robustness in the face of solve_game() failing toSimon Tatham2005-09-11
| | | | | | return an error message. [originally from svn r6288]
* 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]
* Patch from Ton van Overbeek to fix a small memory leak inSimon Tatham2005-09-04
| | | | | | midend_solve(). [originally from svn r6271]
* Another global environment-variable override across all games. ThisSimon Tatham2005-09-04
| | | | | | | one is <game>_TILESIZE, adjusting the game's default size. I anticipate that this will probably _mostly_ be useful for debugging. [originally from svn r6269]
* Native Windows printing support, using the infrastructure I put inSimon Tatham2005-08-20
| | | | | | | | | | | | | | | | | | | | | place in r6190. I'm quite pleased that I didn't have to modify the printing infrastructure _at all_ to make this work; the only source change required outside windows.c was the addition of a trivial utility function midend_get_params(), and that was for the benefit of bulk puzzle generation rather than anything to do with actual printing. As far as I can tell, all printable puzzles now print almost indistinguishably from the way they print under Unix. If you look closely the font is slightly different, and the Windows standard hatching doesn't seem to be quite as nice as the kind I did by hand in ps.c (and, particularly annoyingly, hatched areas don't show up at all for me when I print to a file and use gv, though they come out fine on the printer itself); but it's all there, and it all works. [originally from svn r6193] [r6190 == af59dcf6858264103bbc621761feee3aed5aaf2a]
* 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]
* Environment-based configuration wasn't sensibly usable in games withSimon Tatham2005-08-04
| | | | | | | spaces in the name. Fixed. (One day I really must get round to turning this into a proper config mechanism.) [originally from svn r6163]
* Solve animation (currently only in Untangle) was failing to setSimon Tatham2005-07-22
| | | | | | | | me->anim_pos to zero, meaning that if it happened immediately after a completion flash then anim_pos would start off half way through its run. [originally from svn r6127]
* New puzzle: `Untangle', cloned (with the addition of random gridSimon Tatham2005-07-16
| | | | | | | | | | | | | | | generation) from a simple but rather fun Flash game I saw this morning. Small infrastructure change for this puzzle: while most game backends find the midend's assumption that Solve moves are never animated to be a convenience absolving them of having to handle the special case themselves, this one actually needs Solve to be animated. Rather than break that convenience for the other puzzles, I've introduced a flag bit (which I've shoved in mouse_priorities for the moment, shamefully without changing its name). [originally from svn r6097]
* 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]
* Change of policy on game_changed_state(). Originally, it was calledSimon Tatham2005-07-10
| | | | | | | | | | | | | | | | | | | | | | by the midend every time the game state changed _other_ than as a result of make_move(), on the basis that when the game state changed due to make_move() the game backend had probably noticed anyway. However, when make_move() split up, this became more fiddly: if the game_ui had to be updated based on some property of the final game state, then execute_move() couldn't do it because it didn't have a pointer to the game_ui, but it was fiddly to do it in interpret_move() because that didn't directly have a copy of the finished game state to examine. Same Game (the only game to be affected) had to deal with this by actually having interpret_move() _call_ execute_move() to construct a temporary new game state, update the UI, and then throw it away. So now, game_changed_state() is called _every_ time the current game state changes, which means that if anything needs doing to the game_ui as a result of examining the new game state, it can be done there and save a lot of effort. [originally from svn r6087]
generated by cgit v1.1 at 2026-05-17 21:47:46 +0000