state is in a solved position, and a midend function wrapping it.
(Or, at least, a situation in which further play is pointless. The
point is, given that game state, would it be a good idea for a front
end that does that sort of thing to proactively provide the option to
start a fresh game?)
[originally from svn r9140]
it clears a clipping region that it knows what features will need
redrawing in that region. Instead, I've moved all the clip/unclip/draw
functionality out into a game_redraw_in_rect() function which checks
_everything_ on the grid to see if it lies in the region.
As far as I can tell the effect only shows up in grid types that
aren't checked in, but it makes the code look nicer too.
(It would be nicer still to avoid the brute-force loop over the whole
grid checking it against the bounding box, particularly when we're
drawing in multiple bounding boxes. But this will do for the moment.)
[originally from svn r9138]
drawn in a face: averaging the vertex positions works fine for regular
or roughly regular convex polygons, but it'll start being a pain for
odder or concave ones.
This is a kludgey brute-force algorithm; I have ideas about more
elegant ways of doing this job, but they're more fiddly, so I thought
I'd start with something that basically worked.
[originally from svn r9137]
they meet at sharp enough angles that the thick lines overlap
noticeably outside the circle of the point - redrawing the edges in a
different order each time looks ugly. Arrange to always redraw edges
in order of colour, so that empty lines are drawn before indeterminate
lines which in turn come before filled-in lines.
[originally from svn r9136]
overly complicated algorithm that uses it to home in on the grid edge
closest to a mouse click. That algorithm is being stressed beyond its
limit by the new grid type, and it's unnecessary anyway given that no
sensibly sized puzzle grid is going to be big enough to make it
prohibitively expensive just to do the trivial approach of iterating
over all edges and finding the closest of the eligible ones.
[originally from svn r9108]
elements to toggle thick lines in the grid. Helps to delineate
subgroups and cosets, so it's easier to remember what you can
legitimately fill in by associativity.
(I should really stop fiddling with this game's UI; it's far too silly.)
[originally from svn r9084]
much easier to keep track of things if, once you've identified a
cyclic subgroup, you can move it into a contiguous correctly ordered
block.
[originally from svn r9075]
(more finished) puzzles in 'unfinished', as Java applets only. (The
rationale being: puzzles in 'unfinished' can be played locally by
people who go to the extra effort of downloading and building the
source, but to play them in Java is particularly inconvenient unless I
build the Java version myself. I just won't link it from the front
page.)
[originally from svn r9073]
Use the puzzle background colour, like the GTK front end does.
(I know that renders the effect of the previous commit invisible,
but it's the principle of the thing! :-)
[originally from svn r9023]
width and height by assuming mirror symmetry within the containing
applet area. Instead, use the proper width and height as given back
by the C sizing function.
(In particular, this fixes a bug where the non-blanked puzzle area
appeared too tall by the height of the menu bar, probably as a
result of confusing PuzzleApplet.getHeight() with
PuzzlePanel.getHeight(). But the mirroring approach was conceptually
wrong anyway.)
[originally from svn r9022]
applies to both drawing mechanisms, and secondly, make sure to paint
the spare pieces of window in the _puzzle's_ background colour
rather than the (sometimes slightly different) system default.
[originally from svn r9021]
[r8997 == 26c669a6b2892b97b4a9bc6842f633291951fdbd]
the size of the rotating sections in Twiddle is a misnomer, since
it's actually measuring something more like the diameter of the
section. Replace the word throughout with 'rotating block size' or
similar.
[originally from svn r9013]
Debian sid (2.20.1), there's a redraw problem when the window has a
different aspect ratio from the puzzle (due to resizing or
maximising): pieces of the window outside the real puzzle rectangle
don't get redrawn when exposed (e.g. by the drop-down menus).
Introduced code to explicitly redraw the whole exposed area,
including the parts that fall outside the pixmap. This makes the
problem go away in my hasty test install of sid, and doesn't seem to
affect the build on lenny.
[originally from svn r8997]
- move critical correctness checks out of diagnostic ifdefs (ahem)
- move declarations to before conditionally compiled code (we don't
build in C99 mode round here)
- tidy up an unsightly blank line while I'm here.
[originally from svn r8969]
draw_thick_line function, and also add some general thoughts on how
to draw puzzles' windows in an antialiasing-friendly way.
[originally from svn r8965]
properly antialiasing-safe: all redraws are now done by clearing a
rectangle of the image, clipping to that rectangle, and redrawing
everything in it exactly once.
[originally from svn r8963]
the drawing API, for use by Loopy. It's optional: drawing.c will
construct an acceptable alternative using a filled polygon if the
front end doesn't provide it.
Net and Netslide previously had static functions called
draw_thick_line(), whose claim to the name is less justified and so
they've been renamed.
[originally from svn r8962]
Cairo rendering library in place of GDK, which provides pretty
antialiased graphics much like we get on MacOS. Inertia and Untangle
are perhaps the two games most obviously improved by this.
[originally from svn r8961]
which I didn't know about, but which is clearly a waste of effort
since we keep our own backing pixmap for the puzzle window.
[originally from svn r8960]
'Yes' and 'No' buttons, which means they get the standard icons that
go on those button types. Also reorders yes/no boxes so that they're
the GNOME standard way round.
[originally from svn r8959]
output (a comment from Recipe mistakenly got into the Unix
makefile); more importantly, lets mkfiles.pl run in up-to-date Perls
(where implicit split to @_ is now obsolete).
[originally from svn r8957]
division clues were failing to light up as erroneous if the quotient
of the numbers in them came out right under rounded-down C integer
division (e.g. 2 and 5 would be accepted for a 2/ clue). Apparently
I copied the code that invents clues in the generator straight into
the solution checker, without remembering that the generator was
allowed to do it that way because exact divisibility had been
checked elsewhere.
[originally from svn r8951]
(Missed off the explicit -o from the compile lines constructing
version.{i386,ppc}.o, causing both to be compiled as version.o and
dependent build steps to fail.)
[originally from svn r8933]
[r8931 == 36cee4e2796c23da15d3276e88416ad1ce035c4a]
of basically unchanged binaries due to the compulsory rebuild of
version.o. version.o now depends normally on version2.def, which is
constructed using much the same if statements that version.o used to
use, except that it's not overwritten at all if its contents don't
need to change.
[originally from svn r8931]
introduce a new colour in Slant (COL_FILLEDSQUARE) which is used for
the background of any grid square that has a diagonal line in it.
This makes it easier to spot the one square on a giant board you
forgot to fill in, but on the other hand I found it to look very
strange and disconcerting. So I've set the colour to be identical to
COL_BACKGROUND by default, and users who like the idea can enable it
by environment variable or by local patch.
[originally from svn r8930]
line with freedesktop.org. (This is relatively simple for Puzzles,
since it only writes to the clipboard and never reads it, so the
question of which selection to use when is most easily dealt with by
always writing to both.)
[originally from svn r8929]
bridges that could go to an island, the game was not correctly
accounting for existing bridges in all circumstances.
(E.g. in 7x7m2:2a6a2a1g4a6c4i1a1h23c2b, connect the top right 1 to
the 2 left of it, and the 6 left of that correctly lights up red.
But now connect the 6 to the 6 below it, and it wrongly unlights
again.)
[originally from svn r8905]
- sometimes two regions would get the same letter
- immutable numbers could sometimes be modified
- immutable numbers are now not flagged as errors when they clash
(same as Solo's policy)
[originally from svn r8882]
reported as potentially-unused. (In fact, as far as I can tell, it's
only ever uninitialised in assertion-failing code paths, so not a
real bug.)
[originally from svn r8873]
