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]
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]
they will only be processed as special by the midend if unwanted by
the backend. This causes 5x5 Solo to become just about playable,
because you can now click in a square and type `n'. However, typing
`n' when a square is not selected will revert to the normal
behaviour of starting a new game.
(This isn't particularly ideal, I know, but it's better than
nothing.)
[originally from svn r6048]
the current midend state even if you don't subsequently enter a
valid one. Reorganise midend_game_id_int() so that (just like
midend_deserialise()) it does all its error checking before altering
anything in the midend's persistent data, so that it either succeeds
completely or fails before doing anything at all.
[originally from svn r6045]
did I miss this before? It just caused a segfault for me, which is
entirely fair enough, but I've no idea why it didn't fail before!
[originally from svn r6043]
- 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]
midend.c. Also I've added an experimental front end in gtk.c only:
`Save' and `Load' options on the Game menu, which don't even show up
unless you define the magic environment variable
PUZZLES_EXPERIMENTAL_SAVE. Once I'm reasonably confident that the
whole edifice is plausibly stable, I'll take that out and turn it
into a supported feature (and also implement it in OS X and Windows
and write documentation).
[originally from svn r6030]
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]
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]
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]
- 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]
- 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]
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]
puzzle of a different size to be redrawn before the pixmap is
resized, and since backends never redraw already-drawn stuff this is
a problem. Was biting me when I entered a Mines game ID of a
different size than the current settings into the Specific box.
[originally from svn r5872]
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]
indicates whether a particular game state should have the timer
going (for Mines the initial indeterminate state does not have this
property, and neither does a dead or won state); a midend function
that optionally (on request from the game) prepends a timer to the
front of the status bar text; some complicated midend timing code.
It's not great. It's ugly; it's probably slightly inaccurate; it's
got no provision for anyone but the game author decreeing whether a
game is timed or not. But Mines can't be taken seriously without a
timer, so it's a start.
[originally from svn r5866]
blank grid until you make the first click; to ensure solubility, it
does not generate the mine layout until that click, and then ensures
it is solvable starting from that position.
This has involved three infrastructure changes:
- random.c now offers functions to encode and decode an entire
random_state as a string
- each puzzle's new_game() is now passed a pointer to the midend
itself, which most of them ignore
- there's a function in the midend which a game can call back to
_rewrite_ its current game description.
So Mines now has two entirely separate forms of game ID. One
contains the generation-time parameters (n and unique) plus an
encoding of a random_state; the other actually encodes the grid once
it's been generated, and also contains the initial click position.
When called with the latter, new_game() does plausibly normal stuff.
When called with the former, it notes down all the details and waits
until the first square is opened, and _then_ does the grid
generation and updates the game description in the midend. So if,
_after_ your first click, you decide you want to share this
particular puzzle with someone else, you can do that fine.
Also in this checkin, the mine layout is no longer _copied_ between
all the game_states on the undo chain. Instead, it's in a separate
structure and all game_states share a pointer to it - and the
structure is reference-counted to ensure deallocation.
[originally from svn r5862]
both get passed a pointer to the game_ui. This means that if they
need to note down information for the redraw function about what
_type_ of flash or animation is required, they now have somewhere to
do so.
[originally from svn r5858]
