outline polygon with a clipping rectangle active. I don't know or
care whether this is GTK or my X server or what, but I'm working
around it by drawing the lines myself, which seems to sort it out.
[originally from svn r6227]
independently discovered an advanced reasoning technique in Map, and
then it occurred to me that since Solo can also be considered as a
graph-colouring game the same technique ought to be applicable. And
it is; so here's a new difficulty level, `Extreme', which sits just
above Advanced. Grids graded `Extreme' by new-Solo will of course
fall into old-Solo's `Unreasonable' category (since they're not
soluble using the old set of non-recursive methods). A brief and
unscientific experiment suggests that about one in six Unreasonable
grids generated by old-Solo are classified Extreme by the new
solver; so the remaining Unreasonable mode (now containing a subset
of the grids it used to) hasn't actually become much harder.
[originally from svn r6209]
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]
(This puzzle is theoretically printable, but I haven't added it in
print.py since there's rather a lot of painful processing required
to get from the game ID to the puzzle's visual appearance. It
probably won't become printable unless I get round to implementing a
more integrated printing architecture.)
[originally from svn r6186]
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]
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]
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]
clues from a filled grid, was using the algorithm
- loop over the whole grid looking for a clue (or symmetry group of
clues) which can be safely removed
- remove it
- loop over the whole grid again, and so on.
This was due to my vague feeling that removing one clue might affect
whether another can be removed. Of course this can happen - two
clues can be alternative ways of deducing the same vital fact so
that removing one makes the other necessary - but what _can't_
happen is for removing one clue to make another _become_ removable,
since you can only do that by _adding_ information. In other words,
after testing a clue and determining that it can't be removed, you
never need to test it again. Thus, a much simpler algorithm is
- loop over the possible clues (or symmetry groups) _once_, in a
random order
- for each clue (group), if it is removable, remove it.
This still guarantees to leave the grid in a state where no further
clues can be removed, but it greatly cuts down puzzle generation
time and also simplifies the code. I am a fool for not having
spotted this in three and a half months!
[originally from svn r6160]
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]
the property which devel.but claimed to be the reason why that
strategy works. A bit of thought revealed what the _real_ reason is
why this strategy works in some puzzles and not others, so I've
rewritten the paragraph to be more accurate.
[originally from svn r6158]
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]
B and some from me. Also an additional utility function
`random_copy' from Richard B, which he says is useful in a new
puzzle he's working on and which seems likely to come in handy again
at some point.
[originally from svn r6153]
positions immediately when you make an error, the game now reveals
as little information as is necessary to prove you wrong (including
none - if an existing laser path you know about is inconsistent with
your guesses, the game will just point it out and tell you nothing
new!) and you can try again. Errors are counted in much the same way
as deaths in Mines.
[originally from svn r6152]
