| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
| |
the back end function solve_game() now takes the _current_
game_state in addition to the initial one.
[originally from svn r5969]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
symmetry which were not implemented in Solo. Now they are.
In the process I've completely retired symmetry_limit() on the
grounds that some of the new symmetries do not have a rectangular
base region; instead I determine the base region by going through
the grid and finding every square which is not transformed into a
lexicographically lower square by any symmetry operation. This means
that adding new symmetries is now _only_ a matter of encoding the
actual transformation rules.
[originally from svn r5965]
|
| |
|
|
|
|
| |
clash-checking code in Solo. (valgrind confirms it.)
[originally from svn r5916]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
and positioned according to how many there are in the cell, rather
than how many distinct digits there are in the entire puzzle. This
means that 4x4 Solo can now be played with pencil marks without
_too_ much difficulty; the marks will still get a bit crowded if you
have more than 12 in the same square, but with luck that shouldn't
happen often, and as long as you're down in the 2-9 range things
should be entirely legible.
[originally from svn r5909]
|
| |
|
|
| |
[originally from svn r5899]
|
| |
|
|
|
|
|
|
|
|
| |
any actual clashes (duplicate numbers in a row, column or block) in
red. This is a non-privileged deduction: it doesn't compare against
a known solution or consult a solver. It simply indicates reasons
why (no superset of) the current grid would cause the completion
flash to go off.
[originally from svn r5898]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- prevent highlighting a clue square at all
- enable easier switching between highlight types by not requiring
a left-click highlight to be left-click-cancelled before
right-clicking, and vice versa
- fix bit-rot in -DSTANDALONE_SOLVER
Also one of mine:
- replicate Richard's -DSTANDALONE_SOLVER fix in Pattern, where it
was also broken.
[originally from svn r5892]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- 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]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(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]
|
| |
|
|
|
|
|
| |
number. Many thanks to Chris Thomas, for helping with the detailed
UI design by means of testing an endless series of prototypes.
[originally from svn r5842]
|
| |
|
|
| |
[originally from svn r5800]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
keypad. The reason it doesn't is because front ends were carefully
translating the numeric keypad into 8-way directional keys for the
benefit of Cube. Therefore, a policy change:
- front ends process the numeric keypad by sending MOD_NUM_KEYPAD |
'3' and similar
- front ends running on a platform with Num Lock SHOULD do this
_irrespective_ of the state of Num Lock
- back ends do whatever they see fit with numeric keypad keys.
Result: the numeric keypad now works in Solo, and also works in OS X
Cube (which it previously didn't because I forgot to implement that
bit of the front end!).
[originally from svn r5774]
|
| |
|
|
| |
[originally from svn r5757]
|
| |
|
|
|
|
|
|
|
|
| |
the missing fifth difficulty level to Solo: `Unreasonable', in which
even set-based reasoning is insufficient and there's no alternative
but to guess a number and backtrack if it didn't work. (Solutions
are still guaranteed unique, however.) In fact it now seems to take
less time to generate a puzzle of this grade than `Advanced'!
[originally from svn r5756]
|
| |
|
|
|
|
|
|
| |
computers, let's save the Solo and Pattern grids at generation time
and regurgitate them when asked to solve, rather than doing all the
work over again.
[originally from svn r5737]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
working.
[originally from svn r5706]
|
| |
|
|
|
|
|
| |
todo list, which complained about this because Solo was the only
puzzle noticeably affected).
[originally from svn r5694]
|
| |
|
|
|
|
| |
round.
[originally from svn r5691]
|
| |
|
|
|
|
| |
terminology as the puzzle GUI.
[originally from svn r5683]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
enable configurable puzzle difficulty. I'm only generating grids up
to Times level (complicated non-recursive analysis but guessing
never required); I wouldn't object to providing a Telegraph
difficulty level (guessing required) but it turns out to be very
hard indeed to generate at random. I might still add it later
(probably under the name `Unreasonable' :-) if I can think of an
efficient way to find them.
[originally from svn r5682]
|
| |
|
|
|
|
|
| |
grid. I'm really starting to get annoyed by the default round-
towards-zero behaviour of C integer division.
[originally from svn r5681]
|
| |
|
|
|
|
|
| |
build, and which is redundant given the new standalone solver
functionality.
[originally from svn r5672]
|
| |
|
|
|
|
| |
checkin.
[originally from svn r5671]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- added a compilation option -DSTANDALONE_SOLVER which makes both
of Solo's internal solvers accessible from the command line.
- fix a bug in nsolve turned up by testing in this mode: it failed
to iterate at all! Oddly, this massive improvement to the
effectiveness of nsolve hasn't emptied the generated grids by
very much.
- add an extra mode of reasoning to my to-do list (which is the
dual of one already there, so I'm kicking myself).
[originally from svn r5670]
|
| |
|
|
|
|
| |
lose a lot of code duplication in nsolve while preserving efficiency.
[originally from svn r5667]
|
| |
|
|
|
|
|
|
| |
the default symmetry from order-4 down to order-2, which seems to
mitigate the excessively-full-grid problem by permitting more
freedom to remove stuff.
[originally from svn r5666]
|
| |
|
|
| |
[originally from svn r5661]
|
|
|
the Times under the name `Sudoku'.
[originally from svn r5660]
|
