otherwise not cause the window size to change caused it to become very small
indeed. This change from Simon fixes that behaviour; I haven't tested it with
Gtk 2.
[originally from svn r6022]
background colour (to ensure white pegs show up against it), and
convert the keyboard-control cursor into a rectangle when it's over
the hint pegs (otherwise it looks rather silly for numbers of pegs
above 4).
[originally from svn r6010]
(so that the hint pegs lit up as `ready') and then pressed Undo: the
markable flag would remain set and the redrawing wouldn't darken the
pegs again.
[originally from svn r6009]
keyboard-control cursors, and when I tried to fix those more
wallpaper bubbles popped up elsewhere. Here's what I think is a
proper fix: a comprehensive overhaul of the redraw code such that,
instead of tracking the cursor positions explicitly in the
drawstate, we instead track for each peg position whether or not a
cursor is currently displayed at that position. So cursor erasing
and cursor drawing become part of the main draw loop rather than a
separate bit on the end.
[originally from svn r6006]
[r5996 == 3d58feb561ef09cf977f710d69a3562529e23f0f]
[r5997 == a46e3266558eaf5cd18ac2a6322af65c196c3655]
benefit of antialiasing platforms such as OS X. Also in this
checkin, fiddle with svn:ignore (there's a new puzzle binary).
[originally from svn r5996]
reorganise the colours so there are fewer of those terribly
computery cyan and magenta shades, and more good old-fashioned
colours with simple names like orange and purple. Finally, change
the `right place' marking peg colour from red to black, in line with
at least _my_ old Mastermind set (I faintly suspect red marker pegs
of being an Americanism) and also so that the marker pegs and the
coloured pegs have no colours in common.
[originally from svn r5995]
introduces a few new utility functions in misc.c, one of which is
the bitmap obfuscator from Mines (which has therefore been moved out
of mines.c).
[originally from svn r5992]
bitmap. Can be used to implement sprite-like animations: for
example, useful for games that wish to implement a user interface
which involves dragging an object around the playing area.
[originally from svn r5987]
generator: (a) take out the `#ifdef SLOW_SYSTEM' because the new
generator is much more efficient, and (b) convert another int to
size_t to prevent the solver going negative in 16-bit ints as a
result.
[originally from svn r5983]
sensible means of generating an initial gridful of rectangles. This
was previously a stupidly non-scalable bit of the Rectangles puzzle
generator: it filled a ludicrously large array with every possible
rectangle that could go anywhere in the grid, picked one at random
and winnowed the list by removing anything that overlapped that one,
then repeated until the list was empty (and therefore the grid was
full except for remaining singleton squares). Total cost was O(N^4)
in both time and space; not pretty.
Richard and Chris's sensible alternative was to place each rectangle
by randomly choosing a so-far-uncovered _square_, and then picking a
random rectangle from the possible ones covering that square. This
means we only have to deal with a small fragment of the rectangle
list at any one time, and we don't have to store the whole lot in
memory; so it's _much_ faster and more scalable, and has virtually
no memory cost.
A side effect of this algorithmic change is that the probability
distribution has altered. When you line up all the possible
_rectangles_ and pick one at random, then obviously the small ones
are going to be in the majority since lots of small ones can fit
into the space taken up by any given big one. So the original
algorithm tends to favour fiddly grids full of lots of tiny
rectangles, which don't tend to be very interesting. But if you
first pick a square and then think about the rectangles that can
surround that square, the small ones are suddenly going to be in the
_minority_ because there are only two ways you can place (say) a 2x1
containing a given square compared to 36 ways you can place a 6x6.
So this algorithm favours more large rectangles, which I generally
consider to be an improvement.
[originally from svn r5982]
redrawn as non-black on undo. Introduce a new flag TILE_IMPOSSIBLE,
so that information about those black markers is cached in the
drawstate and we know when we have to erase them.
In the process I've removed the game_state argument completely from
the subfunction tile_redraw(), which gives me some confidence that
it isn't getting any _more_ privileged information out of it.
[originally from svn r5979]
Windows for puzzles with status bars, because the initial call to
check_window_size is given the window size _without_ the status bar
and assumes that that has to be big enough for the whole thing
_with_ the status bar, so it shrinks everything by a little bit. So
now we resize the window to take account of the status bar before
calling check_window_size(), and the problem seems to have gone away.
[originally from svn r5975]
(solving it only requires matrix inversion over GF(2), whereas
several of the other puzzles in this collection are NP-complete in
principle), but it's a fun enough thing to play with and is
non-trivial to do in your head - especially on the hardest preset.
[originally from svn r5967]
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]
from saying `Auto-solved' or `Completed', the main function of the
status bar is to track the current size of a rectangle you're
dragging out, which makes life much easier when trying to count up
large rectangles in 19x19 mode.
[originally from svn r5937]
gdk_font_from_description() will no longer even _try_ to return a
font matching the specified Pango font description; instead it will
return `fixed' no matter what you do. Therefore, I've had to switch
to using Pango proper for Puzzles text rendering, rather than just
using Pango for font selection.
[originally from svn r5936]
