- 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]
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]
Jacob wasn't able to find a satisfactory fix: the whole area was a
horrid mess. Fortunately, the reason it was a horrid mess was
because the Net drawing routines predated the introduction of clip()
in the frontend interface, and it turns out that clip() makes it
possible to do all this more easily and better. So, a complete
rearchitecting of barrier corners: the corner flags in the
`barriers' array are now gone (and good riddance), and corner
information is computed on the fly so as to take into account the
moving grid edges. In the process I've also updated the corner
mechanism so that a barrier `corner' (really endpoint) is drawn at
the end of _every_ barrier, not just where two meet. This has
changed the appearance of a single isolated barrier, to what I would
have wanted it to look like in the first place but achieving it
without clip() was just too fiddly.
[originally from svn r5846]
[r5844 == 865e8ad6ca3d83ad2a585ceeb1809e9f68c18a20]
(Adding modifier+cursors handling has had minor knock-on effects on the other
puzzles, so that they can continue to ignore modifiers.)
(An unfortunate side effect of this is some artifacts in exterior barrier
drawing; notably, a disconnected corner can now appear at the corner of the
grid under some circumstances. I haven't found a satisfactory way round
this yet.)
[originally from svn r5844]
unique solution. This, it turns out, is because there is literally
no such thing. Protective constraint added to validate_params(),
with a proof in a comment alongside.
If you really want a 2xn or nx2 wrapping puzzle, you can still have
one if you turn uniqueness off.
[originally from svn r5835]
The previous checkin stopped it choking on them, but it didn't
actually manage to _deduce_ that all the edges bordering them had to
be closed. Now it does better.
[originally from svn r5829]
over on a grid containing a 0 (completely blank) tile. This can't
happen in self-generated grids, but can happen if you type in a grid
from another Net implementation. Previously, the solver would notice
(technically correctly!) that a completely blank tile connects to no
other tiles and thus forms an isolated subgraph, and would therefore
complain that no orientation of that tile could possibly yield a
valid solution...
[originally from svn r5828]
- fix documentation of Net's unique solution option (should have
tested before last checkin)
- make unique solutions optional in Rectangles too (same reasons)
- tidy up various issues in parameter encoding in both games.
[originally from svn r5818]
enabled by default), since ambiguous sections in grids can present
additional interesting challenges. I think uniqueness is a better
default, though.
[originally from svn r5816]
rather than literal grid descriptions, which has always faintly
annoyed me because it makes it impossible to type in a grid from
another source. However, Gareth pointed out that short random-seed
game descriptions are useful, because you can read one out to
someone else without having to master the technology of cross-
machine cut and paste, or you can have two people enter the same
random seed simultaneously in order to race against each other to
complete the same puzzle. So both types of game ID seem to have
their uses.
Therefore, here's a reorganisation of the whole game ID concept.
There are now two types of game ID: one has a parameter string then
a hash then a piece of arbitrary random seed text, and the other has
a parameter string then a colon then a literal game description. For
most games, the latter is identical to the game IDs that were
previously valid; for Net and Netslide, old game IDs must be
translated into new ones by turning the colon into a hash, and
there's a new descriptive game ID format.
Random seed IDs are not guaranteed to be portable between software
versions (this is a major reason why I added version reporting
yesterday). Descriptive game IDs have a longer lifespan.
As an added bonus, I've removed the sections of documentation
dealing with game parameter encodings not shown in the game ID
(Rectangles expansion factor, Solo symmetry and difficulty settings
etc), because _all_ parameters must be specified in a random seed ID
and therefore users can easily find out the appropriate parameter
string for any settings they have configured.
[originally from svn r5788]
various things:
- if you haven't fully understood what a game is about, it gives
you an immediate example of a puzzle plus its solution so you can
understand it
- in some games it's useful to compare your solution with the real
one and see where you made a mistake
- in the rearrangement games (Fifteen, Sixteen, Twiddle) it's handy
to be able to get your hands on a pristine grid quickly so you
can practise or experiment with manoeuvres on it
- it provides a good way of debugging the games if you think you've
encountered an unsolvable grid!
[originally from svn r5731]
constructed at the same time as an internally generated game seed,
so that it can preserve any interesting information known by the
program at generation time but not physically contained within the
text of the game seed itself. (Such as, for example, the solution.)
Currently not used for anything yet, but it will be.
[originally from svn r5729]
as text. This is used by front ends to implement copy-to-clipboard.
Currently the function does nothing (and is disabled) in every game
except Solo, but it's a start.
[originally from svn r5724]
definitions, so let's move it so that it's just next to the
functions it relates to. This also opens the way for me to add more
booleans next to other functions without getting confused as to
which is which.
[originally from svn r5723]
functions and a couple of variables, now each one exports a single
structure containing a load of function pointers and said variables.
This should make it easy to support platforms on which it's sensible
to compile all the puzzles into a single monolithic application. The
two existing platforms are still one-binary-per-game.
[originally from svn r5126]
tiles randomly. (Rachel asked for this; it's been being tested for a good few
months now, and Simon didn't care either way, so in it goes :)
As part of this, the front end can now be asked to provide a random random
seed (IYSWIM).
[originally from svn r5019]
argument `dir' which tells them whether this redraw is due to an undo, rather
than have them second-guess it from game state.
Note that none of the actual games yet take advantage of this; so it hasn't
been tested in anger (although it has been inspected by debugging).
[originally from svn r4469]
parameters as a string, and decode it again. This is used in
midend.c to prepend the game parameters to the game seed, so that
copying out of the Specific box is sufficient to completely specify
the game you were playing.
Throughout development of these games I have referred to `seed'
internally, and `game ID' externally. Now there's a measurable
difference between them! :-)
[originally from svn r4231]
addition to the `game_state'. The new structure is intended to
contain ephemeral data pertaining to the game's user interface
rather than the actual game: things stored in the UI structure are
not restored in an Undo, for example.
make_move() is passed the UI to modify as it wishes; it is now
allowed to return the _same_ game_state it was passed, to indicate
that although no move has been made there has been a UI operation
requiring a redraw.
[originally from svn r4207]
specifically, the elapsed time between calls varies much more with
GTK than it does under Windows. Therefore, I now take my own time
readings on every timer call, and this appears to have made the
animations run at closer to the same speed between platforms. Having
done that, I decided some of them were at the _wrong_ speed, and
fiddled with each game's timings as well.
[originally from svn r4189]
is (a) pretty feeble, and (b) means that although Net seeds transfer
between platforms and still generate the same game, there's a
suspicious discrepancy in the typical seed _generated_ by each
platform.
I have a better RNG kicking around in this code base already, so
I'll just use it. Each midend has its own random_state, which it
passes to new_game_seed() as required. A handy consequence of this
is that initial seed data is now passed to midend_new(), which means
that new platform implementors are unlikely to forget to seed the
RNG because failure to do so causes a compile error!
[originally from svn r4187]
mechanism I've just invented (the midend handles the standard game
selection configuration). Each game is now required to validate its
own seed data before attempting to base a game on it and potentially
confusing itself.
[originally from svn r4186]
taking non-zero time, which is triggered by the making of a move and
is _not_ hurried to its conclusion by the start of the next move (so
the game redraw function is expected to be able to draw it in
parallel with continuing moves). The only thing that prematurely
terminates a flash is the start of a fresh flash. In particular,
this concept is used to display the completion flash in Net, because
at least _my_ playing instincts make me lock every piece I've
unambiguously placed, and hence the last turn move is instantly
followed by a lock move which was previously suppressing the
completion flash.
[originally from svn r4168]
are now expected to provide a list of `presets' (game_params plus a
name) which are selectable from the menu. This means I can play
both Octahedron and Cube without recompiling in between :-)
While I'm here, also enabled a Cygwin makefile, which Just Worked.
[originally from svn r4158]
