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]
large puzzles. Resort to hand-hacked 64-bit arithmetic for doing dot
products; everything else remains in `long' for the moment.
(Ideally I'd auto-detect the presence of `long long' and use it in
place of my cheap plastic imitation where possible, but since I
currently don't have a configure mechanism that'll have to wait.)
[originally from svn r6137]
`-DSHOW_CROSSINGS', it will show each edge in red if it is crossed
by anything, and in black otherwise. Distracting and not
particularly useful during play, but occasionally handy for
debugging cross().
[originally from svn r6136]
either a game ID or a save file name. (The former takes priority,
because you can usually find a synonym for the latter, such as by
prepending `./' or `$PWD/'.)
[originally from svn r6135]
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]
to bring it as close as possible to the current game state. This
means that if you request `Solve' after solving a puzzle yourself,
with the intention of finding out how similar your solution is to
the program's, then you will mostly see the differences in _shape_
rather than those being masked by the fact that yours happened to be
the other way up.
[originally from svn r6126]
was spending 60% of its time in shuffle(). The purpose of the
shuffle() call was to go through a largish array in random order
until we found an element that worked, so there's no actual need to
shuffle the whole array every time and I only did it out of
laziness. So I now pick a random element each time I go round the
loop, meaning I save a lot of shuffling effort whenever the loop
terminates early (which is often). I get about a factor of two speed
improvement from this small change.
[originally from svn r6125]
which is unable to guarantee that every grid it generates can be
solved. So I'm eliminating that exception: this checkin contains a
more sophisticated grid generator which does guarantee solubility.
It's a bit slow (most noticeably on the 15x10c3 preset), and the
quality of the generated grids is slightly weird (a tendency toward
small regions rather than large sweeping areas of contiguous
colour); however, I'm willing to see the latter as a feature for
now, since making the game more challenging while simultaneously
guaranteeing it to be possible sounds like an all-round win to me.
From now on I'm raising my standards for contributions to this
collection. I made this fix to Same Game because I heard a user
_automatically assume_ that any puzzle in my collection would not be
so uncouth as to generate an impossible grid; as of this checkin
that's actually true, and I intend to maintain that standard of
quality henceforth.
(Guaranteeing a _unique_ solution is more of an optional extra,
since there are many games for which it isn't a meaningful concept
or isn't particularly desirable. Which is not to say that _some_
games wouldn't be of unacceptably low quality if they failed to
guarantee uniqueness; it depends on the game.)
[originally from svn r6124]
$(XFLAGS) _after_ $(CFLAGS) on the compiler command lines, meaning
that you can provide options in XFLAGS on the makefile which will
override the ones in CFLAGS. For example, `make XFLAGS=-O0' to make
debugging easier.
[originally from svn r6123]
bit. In particular, it now flashes between _two_ specially picked
colours (white and mid-grey), meaning that it should be visible even
if your default background colour is white; and it also flashes
twice rather than once.
[originally from svn r6121]
more than 36 distinct symbols (it runs out of alphanumerics), check
this in validate_params. I hate to do this, since I like puzzle
sizes to at least be open-ended in _principle_, but in this case
there's a fundamental UI limitation which won't be fixed by getting
a faster CPU.
[originally from svn r6098]
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]
do during construction which massively increases (by over a factor
of four with default parameters) the probability that any given
randomly generated grid will be uniquely solvable.
[originally from svn r6096]
- use the new `shuffle' utility function in a couple of places
- remove the random_state parameter from solver(). It was there
because I initially wanted to use the same solver for grid
generation, but since I had to abandon that plan the solver now
doesn't have any need for randomness at all.
[originally from svn r6093]
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]
button interface (same button to open a closed square or to clear
around an open one) to be a massive help, there is one circumstance
in which it frequently kills me: if I click down on an open square I
want to clear around, then the mouse pointer accidentally drifts
over on to the nearest closed square before I release, I'll end up
opening that square instead and (usually) dying. So this checkin
causes Mines to note which type of square I left-clicked on, and to
do nothing if the button release is on the other type.
[originally from svn r6086]
with the obvious central hole it presents you with a randomly chosen
one of twelve other holes. The reason is, the central-hole starting
position is provably insoluble (proof given in comments), so instead
we pick from the ones that are actually possible.
[originally from svn r6083]
capability added to it, to be used only when all else fails, and is
simply called `solver'. This means that:
- solving of 5x5 Trivial grids using the `Solve' function, which
previously hung for ages because rsolve happened to take a wrong
turning at the start, is now zippy
- solosolver doesn't require the confusing -r and -n options
- solosolver can show its working even for Unreasonable grids.
Unfortunately, the new unified solver still isn't suitable for grid
generation. After it proved to be so much faster at solving 5x5s, I
hoped to be able to substitute it for rsolve during generation and
gain additional speed in 5x5 generation too; but no luck, because
it's slower _per recursion level_, and although during solving it
makes up for this by needing very few levels, there is a lot of
_unavoidable_ recursion during generation, especially at 5x5. A
hybrid strategy which starts off with rsolve and switches to the
unified solver at a critical point proved unsatisfactory as well,
because the critical point changes depending on the vagaries of the
recursion and can't be pinpointed easily. So rsolve is still in
there, only renamed `gridgen' because that's now all it's good for.
[originally from svn r6077]
- reinstate the initialisation of ds->w and ds->h in guess.c, which
I'd accidentally removed during game_size() refactoring
- reorganise Net's interpret_move() so that my uncommitted patch
for drag-based UI (which he uses on the Palm port) will apply
more easily
- the interpret_move() changes make it easy to have a single move
type which rotates a tile by 180 degrees, so this is now provided
via the `F' key (but there's no spare button available to provide
it via the mouse).
[originally from svn r6070]
scheme in r6068, since this messed up the non-permanency of the non-limited
parameter.
[originally from svn r6069]
[r6068 == f3c95109c7b905f74b5f149eea21f68444c31ef7]
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]
command-line programs (solosolver, patternsolver, mineobfusc) to be
built as part of the normal Makefiles. This means mkfiles.pl now has
the capability to compile a source file more than once with
different #defines. Also, fixes for those auxiliary programs and one
fix in midend.c which the Borland compiler objected to while I was
testing its makefile generation.
[originally from svn r6066]
