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.
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.
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.
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
_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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
