| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
fallback behaviour as PuTTY's support.
[originally from svn r7009]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
believe a square to be empty, you find out instantly and lethally,
but if you erroneously believe a square to be full you can
occasionally (when it doesn't cause a complementary square to be
assumed empty) not notice until you find at the very end of the game
that you're one mine heavy. To help with this, here's an error
highlighting patch: any number square surrounded by an excess of
flags will now light up red. This should be an unintrusive change,
because it will never happen unless you make a mistake.
[originally from svn r6580]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which didn't actually need it. It was originally introduced in
Fifteen to suppress animation on Solve moves, but midend.c now does
that centrally unless the game specifically instructs it otherwise.
Therefore, just_used_solve is obsolete in all games which previously
used it. (Mines was even worse: it scrupulously maintained the
correctness of the field but never used it!)
Untangle is exempt from this cleanup: its `just_solved' field is
used to change the _length_ of the animation on Solve moves, not to
suppress it entirely, and so it has to stay.
[originally from svn r6419]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
| |
shift right. It doesn't actually matter in the current code since
the input word only ever uses the bottom 9 bits, but if I ever
extended Mines to work in a triangular grid then all 16 bits might
be required. Fix this now, while I'm cleaning things up, so that it
won't bite me unexpectedly in future.
[originally from svn r6415]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
| |
redraw the whole window _every_ time game_redraw() was called during
a flash. Now they only redraw the whole window every time the
background colour actually changes. Thanks to James H for much of
the work.
[originally from svn r6166]
|
| |
|
|
| |
[originally from svn r6147]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint: because some front ends interpret `draw filled shape' to
mean `including its boundary' while others interpret it to mean `not
including its boundary' (and X seems to vacillate between the two
opinions as it moves around the shape!), you MUST NOT draw a filled
shape only. You can fill in one colour and outline in another, you
can fill or outline in the same colour, or you can just outline, but
just filling is a no-no.
This leads to a _lot_ of double calls to these functions, so I've
changed the interface. draw_circle() and draw_polygon() now each
take two colour arguments, a fill colour (which can be -1 for none)
and an outline colour (which must be valid). This should simplify
code in the game back ends, while also reducing the possibility for
coding error.
[originally from svn r6047]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- 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]
|
| |
|
|
|
|
|
| |
meant that a Mines game saved before the first click had taken place
could not be successfully reloaded.
[originally from svn r6036]
|
| |
|
|
| |
[originally from svn r6031]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Firstly, the `Restart' function now reconstructs an initial game
state from the game description rather than dup_game(states[0]).
This means that Restart in a game of Mines restarts to just _after_
the initial click, so you can resume the puzzle-solving part without
having to remember where you placed that click.
Secondly, the midend now contains a second `private' game desc,
which is guaranteed to actually reconstruct the initial game_state
correctly (which Mines's publicly visible game descs tend not to,
since they describe a state which has already had the first click).
This should make serialising of Mines more sensible.
[originally from svn r6025]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
introduces a few new utility functions in misc.c, one of which is
the bitmap obfuscator from Mines (which has therefore been moved out
of mines.c).
[originally from svn r5992]
|
| |
|
|
|
|
|
| |
the back end function solve_game() now takes the _current_
game_state in addition to the initial one.
[originally from svn r5969]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of these recently) whose job is to update a game_ui to be consistent
with a new game_state. This is called by midend.c in every situation
where the current game_state changes _other_ than as a result of
make_move (Undo, Redo, Restart, Solve).
The introduction of this function allows a game_ui to contain
information about selections or highlights within a game_state which
simply wouldn't make sense when transferred to another game_state.
In particular, I've used it to fix a subtle bug in Solo whereby,
although you couldn't right-click to pencil-mode highlight a filled
square, you could _get_ a pencil-mode highlight in a filled square
if you used Undo and Redo. (Undo to before the square was filled,
right-click to highlight it, then Redo. Alternatively, left-click
and clear the square, right-click to highlight it, then Undo.)
[originally from svn r5912]
|
| |
|
|
|
|
|
|
| |
their coordinates were outside the playing area. Clearly no actual
move should be made in that situation, but we do at least need to
sort out any highlighted squares from the prior dragging operations.
[originally from svn r5911]
|
| |
|
|
|
|
|
|
|
|
|
| |
mine density without (as you would with a conventional random grid
generator) rendering the game completely unplayable. High mine
densities are really good fun, and the point of the presets menu is
to provide people with pre-tested good settings and things they
might not have thought to try for themselves; so here are three
additional presets with high densities.
[originally from svn r5906]
|
| |
|
|
|
|
|
|
|
|
| |
utility to convert descriptive game IDs containing mine bitmaps
between obfuscated and cleartext. Might be handy for anyone planning
to design custom levels to send to friends (mines spelling out
`Happy Birthday', that sort of thing), as someone suggested to me
today :-)
[originally from svn r5903]
|
| |
|
|
|
|
|
| |
haven't checked in Makefile changes to enable this, but I'll at
least fix the specific problems it found when enabled as a one-off.
[originally from svn r5902]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- fixed numerous memory leaks (not Palm-specific)
- corrected a couple of 32-bit-int assumptions (vital for Palm but
generally a good thing anyway)
- lifted a few function pointer types into explicit typedefs
(neutral for me but convenient for the source-munging Perl
scripts he uses to deal with Palm code segment rules)
- lifted a few function-level static arrays into global static
arrays (neutral for me but apparently works round a Palm tools
bug)
- a couple more presets in Rectangles (so that Palm, or any other
slow platform which can't handle the larger sizes easily, can
still have some variety available)
- in Solo, arranged a means of sharing scratch space between calls
to nsolve to prevent a lot of redundant malloc/frees (gives a 10%
speed increase even on existing platforms)
[originally from svn r5897]
|
| |
|
|
|
|
| |
be between interactive and batch use.
[originally from svn r5896]
|
| |
|
|
|
|
|
|
|
| |
hanging the grid generator and that there's no way to fix it.
Therefore, lower limit of 3 squares in each direction, which will
upset envelope-pushers everywhere but doesn't destroy any actually
interesting puzzles.
[originally from svn r5895]
|
| |
|
|
|
|
|
| |
the grid, in all games that have them, are drawn incorrectly when
the grid is not square. Fixed.
[originally from svn r5893]
|
| |
|
|
| |
[originally from svn r5890]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- middle button now also triggers the clear-around-square action
- a special-case handler in midend_process_key() arranges that the
left button always trumps the right button if both are pressed
together, meaning that Windows Minesweeper players used to
pressing L+R to clear around a square should still be able to do
so without any strange behaviour.
(The latter touches all game backends, yet again, to add a field to
the game structure which is zero in everything except Mines.)
[originally from svn r5888]
|
| |
|
|
| |
[originally from svn r5887]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than revealing the entire mine layout when you die, we now
only reveal the one mine that killed you. You can then Undo and
continue playing, without having spoiled the rest of the grid for
yourself. The number of times you've died is counted in the status
line (and is not reduced by Undo :-).
Amusingly, I think this in itself is quite a good way of dealing
with ambiguous sections in a Minesweeper grid: they no longer
_completely_ spoil your enjoyment of the game, because you can still
play the remainder of the grid even if you haven't got a completely
clean sweep. Just my luck that I should invent the idea when I've
already arranged for ambiguous sections to be absent :-)
[originally from svn r5886]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the Mines unique grid generator fails at high mine densities it is
_almost always_ for the same reason, and it also turns out that this
reason is one which can be addressed. So here's an enhancement to
mineperturb() which enables Mines to generate a grid at (as far as I
can tell) any mine density you like, up to and including w*h-9
mines. At densities of 1 in 2 or thereabouts the grids start to look
rather strange, but it can at least generate them without hanging.
[originally from svn r5885]
|
| |
|
|
|
|
| |
been causing some of Verity's nonreproducible weirdnesses.
[originally from svn r5884]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
function rather less uniform-looking than I'd intended. I _thought_
it looked a bit fishy, but had assumed it was just the human
tendency to see patterns where none exist. Now fixed, and some real
test vectors confirm that this time the obfuscation function is
actually what I intended it to be.
This means that all masked game IDs generated before this revision
are now invalid. That's a shame, but the game is only a day old and
I think I can reasonably justify it as teething trouble.
[originally from svn r5883]
|
| |
|
|
| |
[originally from svn r5882]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and it moves the polyhedron in the general direction of the mouse
pointer. (I had this in my initial throwaway Python implementation
of this game, but never reimplemented it in this version. It's
harder with triangles, but not too much harder.)
Since the logical-to-physical coordinate mapping in Cube is
dynamically computed, this has involved an interface change which
touches all puzzles: make_move() is now passed a pointer to the
game_drawstate, which it may of course completely ignore if it
wishes.
[originally from svn r5877]
|
| |
|
|
|
|
|
|
|
|
| |
background colour for covered and uncovered squares in Mines, since
otherwise you have to distinguish them by the edge highlights alone.
So here one is; it's not _very_ different (it just looked odd if it
was any darker than this), but anyone who wants a bigger difference
can reconfigure it using the MINES_COLOUR_1 environment variable.
[originally from svn r5876]
|
| |
|
|
| |
[originally from svn r5873]
|
| |
|
|
| |
[originally from svn r5871]
|
| |
|
|
|
|
|
|
|
| |
between on the one hand generating indeterminate game descriptions
awaiting the initial click, and on the other hand generating
concrete ones which have had their initial click. This makes `mines
--generate' do something useful.
[originally from svn r5869]
|
| |
|
|
| |
[originally from svn r5868]
|
