structures, meaning that ad-hoc initialisation now doesn't work.
Hence, this checkin converts all ad-hoc dsf initialisations into
calls to dsf_init() or snew_dsf(). At least, I _hope_ I've caught
all of them.
[originally from svn r6888]
generalisation of the previous deduction involving two 3s or two 1s
either adjacent or separated by a row of contiguous 2s. I always
said that was an ugly loop and really ought to arise naturally as a
special case of something more believable, and here it is.
The practical upshot is that Hard mode has just become slightly
harder: some grids generated by the new Slant will be unsolvable by
the old one's solver. I don't think it's become _excessively_ more
hard; I think I'm happy with the new difficulty level. (In
particular, I don't think the new level is sufficiently harder than
the old to make it worth preserving the old one as Medium or
anything like that.)
[originally from svn r6591]
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]
game_print(), wherever feasible. This fixes a specific bug in Loopy
(James H's new field ds->linewidth wasn't being set up, leading to
corrupted print output), but I've made the change in all affected
files because it also seems like a generally good idea to encourage
it for future games, to prevent other problems of this type.
There is one slight snag, which is that Map _can't_ do this because
its game_set_size() also initialises a blitter. I could fix this by
abstracting the common parts of Map's game_set_size() out into a
subfunction called by game_set_size() and also called directly by
game_print(); alternatively, I could introduce a means of
determining whether a `drawing *' was for screen or printing use.
Not sure which yet.
[originally from svn r6340]
completion, _again_. In r6174 I changed it from dsf to conventional
graph theory so that it could actually highlight loops as opposed to
just discovering that one existed. Unfortunately, yesterday I
discovered a fundamental graph-theoretic error in the latter
algorithm: if you had two entirely separate loops connected by a
single path, the path would be highlighted as well as the loops.
Therefore, I've reverted to the original dsf technique, combined
with a subsequent pass to trace around each loop discovered. This
version seems to do a better job of only highlighting the actual
loops.
[originally from svn r6283]
[r6174 == 2bd8e241a93165a99f5e2c4a2dd9c3b3b1e3c6f3]
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]
to have some means of automatically spotting this sort of problem on
a desktop platform, but I can't immediately think of one; building a
trick compiler which thinks `int' is 16 bits would be the obvious
option, but it would immediately break the ABIs to all the system
functions.
[originally from svn r6184]
slash in this square is red, so it does indeed imply that some of
the edge markings are also red; but it doesn't mean _all_ the edge
markings must be red. So instead of assuming ERRSLASH implies all
edge error markers, we set the correct set of edge error markers at
the same time as setting ERRSLASH, at which point we know which kind
of slash it is so we know which ones to set.
[originally from svn r6175]
in red if it's impossible to fulfill them (either through too many
neighbours connecting to them, or too many not connecting to them),
and edges are highlighted in red if they form part of a loop.
In order to do this I've had to revamp the redraw function
considerably. Each square is now drawn including its top and left
grid edges, but _not_ its bottom or right ones - which means that I
need to draw an extra strip of empty squares outside the actual grid
in order to draw the few pixels which appear on the grid bottom and
right borders and also to red-highlight border clues.
[originally from svn r6174]
to reverse the effect of the mouse buttons. Gareth has been
complaining about this for days: apparently he finds precisely the
opposite control system intuitive to me.
This is a horrendous hack, and pushes me one step closer to losing
my temper and designing a proper preferences architecture.
[originally from svn r6168]
Also in this checkin (committed by mistake - I meant to do it
separately), a behind-the-scenes change to Slant to colour the two
non-touching classes of diagonals in different colours. Both colours
are set to black by default, but configuration by way of
SLANT_COLOUR_* can distinguish them if you want.
[originally from svn r6164]
the return value rather than in *error. In the old days type-
checking would have caught this, but now of course they're the same
type.
[originally from svn r6161]
or two, a debugging fix, a couple of explicit initialisations of
variables that were previously read uninitialised, and a fix for a
whopping great big memory leak in Slant owing to me having
completely forgotten to write free_game().
[originally from svn r6159]
nikoli.co.jp (which has quite a few puzzles that they don't seem to
have bothered to translate into English).
Minor structural change: the disjoint set forest code used in the
Net solver has come in handy again, so I've moved it out into its
own module dsf.c.
[originally from svn r6155]
