| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't know how I've never thought of this before! Pretty much every
game in this collection has to have a mechanism for noticing when
game_redraw is called for the first time on a new drawstate, and if
so, start by covering the whole window with a filled rectangle of the
background colour. This is a pain for implementers, and also awkward
because the drawstate often has to _work out_ its own pixel size (or
else remember it from when its size method was called).
The backends all do that so that the frontends don't have to guarantee
anything about the initial window contents. But that's a silly
tradeoff to begin with (there are way more backends than frontends, so
this _adds_ work rather than saving it), and also, in this code base
there's a standard way to handle things you don't want to have to do
in every backend _or_ every frontend: do them just once in the midend!
So now that rectangle-drawing operation happens in midend_redraw, and
I've been able to remove it from almost every puzzle. (A couple of
puzzles have other approaches: Slant didn't have a rectangle-draw
because it handles even the game borders using its per-tile redraw
function, and Untangle clears the whole window on every redraw
_anyway_ because it would just be too confusing not to.)
In some cases I've also been able to remove the 'started' flag from
the drawstate. But in many cases that has to stay because it also
triggers drawing of static display furniture other than the
background.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Rockbox frontend allows games to be displayed in a "zoomed-in"
state targets with small displays. Currently we use a modal interface
-- a "viewing" mode in which the cursor keys are used to pan around
the rendered bitmap; and an "interaction" mode that actually sends
keys to the game.
This commit adds a midend_get_cursor_location() function to allow the
frontend to retrieve the backend's cursor location or other "region of
interest" -- such as the player location in Cube or Inertia.
With this information, the Rockbox frontend can now intelligently
follow the cursor around in the zoomed-in state, eliminating the need
for a modal interface.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is the main bulk of this boolification work, but although it's
making the largest actual change, it should also be the least
disruptive to anyone interacting with this code base downstream of me,
because it doesn't modify any interface between modules: all the
inter-module APIs were updated one by one in the previous commits.
This just cleans up the code within each individual source file to use
bool in place of int where I think that makes things clearer.
|
| |
|
|
|
|
| |
This commit removes the old #defines of TRUE and FALSE from puzzles.h,
and does a mechanical search-and-replace throughout the code to
replace them with the C99 standard lowercase spellings.
|
| |
|
|
|
|
|
|
|
|
|
| |
encode_params, validate_params and new_desc now take a bool parameter;
fetch_preset, can_format_as_text_now and timing_state all return bool;
and the data fields is_timed, wants_statusbar and can_* are all bool.
All of those were previously typed as int, but semantically boolean.
This commit changes the API declarations in puzzles.h, updates all the
games to match (including the unfinisheds), and updates the developer
docs as well.
|
| |
|
|
|
|
|
|
| |
This function gives the front end a way to find out what keys the back
end requires; and as such it is mostly useful for ports without a
keyboard. It is based on changes originally found in Chris Boyle's
Android port, though some modifications were needed to make it more
flexible.
|
| |
|
|
|
| |
They're never dynamically allocated, and are almost always string
literals, so const is more appropriate.
|
| |
|
|
|
|
| |
This allows me to use different types for the mutable, dynamically
allocated string value in a C_STRING control and the fixed constant
list of option names in a C_CHOICES.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now midend.c directly tests the returned pointer for equality to this
value, instead of checking whether it's the empty string.
A minor effect of this is that games may now return a dynamically
allocated empty string from interpret_move() and treat it as just
another legal move description. But I don't expect anyone to be
perverse enough to actually do that! The main purpose is that it
avoids returning a string literal from a function whose return type is
a pointer to _non-const_ char, i.e. we are now one step closer to
being able to make this code base clean under -Wwrite-strings.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now, with an odd grid size, we choose the posterisation threshold so
that half the time it delivers ceil(n/2) black squares and half the
time it delivers floor(n/2). Previously it only did the former, which
meant that asking Pattern to generate a 1x1 puzzle (with the bug in
the previous commit fixed) would always generate the one with a single
black square, and never the one with a single white square. Both are
trivial to solve, of course, but it seemed inelegant!
No change to the number of black squares in the puzzle solution can
constitute a spoiler for the player, of course, because that number is
trivial to determine without doing any difficult reasoning, just by
adding up all the clues in one dimension.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We were filling in a row immediately as all-white if it had no clues
at all, but weren't filling in a row as all-black if it had a single
clue covering the entire row. Now we do both.
In particular, this caused the Pattern solver to be unable to take
advantage of one of the two kinds of totally obvious clue across the
_easy_ dimension of a trivial 1xN puzzle - and a special case of
_that_, as a user pointed out, is that the game generator hangs trying
to create a 1x1 puzzle, which ought to be the easiest thing in the
world!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To do this, I've completely replaced the API between mid-end and front
end, so any downstream front end maintainers will have to do some
rewriting of their own (sorry). I've done the necessary work in all
five of the front ends I keep in-tree here - Windows, GTK, OS X,
Javascript/Emscripten, and Java/NestedVM - and I've done it in various
different styles (as each front end found most convenient), so that
should provide a variety of sample code to show downstreams how, if
they should need it.
I've left in the old puzzle back-end API function to return a flat
list of presets, so for the moment, all the puzzle backends are
unchanged apart from an extra null pointer appearing in their
top-level game structure. In a future commit I'll actually use the new
feature in a puzzle; perhaps in the further future it might make sense
to migrate all the puzzles to the new API and stop providing back ends
with two alternative ways of doing things, but this seemed like enough
upheaval for one day.
|
| |
|
|
|
|
|
|
| |
This utility works basically the same as galaxiespicture: you feed it
a .xbm bitmap on standard input, and it constructs a game ID which
solves to exactly that image. It will pre-fill some squares if that's
necessary to resolve ambiguity, or leave the grid completely blank if
it can.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The game previously only supported numeric clues round the edge; but
if for some reason you really want a puzzle with a specific solution
bitmap and that bitmap doesn't happen to be uniquely soluble from only
its row and column counts, then this gives you a fallback approach of
pre-filling a few grid squares to resolve the ambiguities.
(This also applies if the puzzle is uniquely soluble *in principle*
but not by Pattern's limited solver - for example, Pattern has never
been able to solve 4x4:2/1/2/1/1.1/2/1/1 and still can't, but now it
can solve 4x4:2/1/2/1/1.1/2/1/1,Ap which has the hard part done for
it.)
Immutable squares are protected from modification during play, and
used as initial information by the solver.
|
| |
|
|
|
|
|
|
|
|
|
| |
The algorithm for deducing how many squares in a row could be filled
in just from the initial clue set was focusing solely on _black_
squares, and forgot that if a row has a totally empty clue square then
everything in it can be filled in as white!
Now the solver can cope with puzzles such as 3x3:/1///1/ , where it
would previously have spuriously considered that it had no idea where
to start.
|
| |
|
|
|
|
| |
The game_state now includes a pointer to a game_state_common
containing all the row and column clues, which is reference-counted
and therefore doesn't have to be physically copied in every dup_game.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
puzzle backend function which ought to have it, and propagate those
consts through to per-puzzle subroutines as needed.
I've recently had to do that to a few specific parameters which were
being misused by particular puzzles (r9657, r9830), which suggests
that it's probably a good idea to do the whole lot pre-emptively
before the next such problem shows up.
[originally from svn r9832]
[r9657 == 3b250baa02a7332510685948bf17576c397b8ceb]
[r9830 == 0b93de904a98f119b1a95d3a53029f1ed4bfb9b3]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
new_desc. Oddities in the 'make test' output brought to my attention
that a few puzzles have been modifying their input game_params for
various reasons; they shouldn't do that, because that's the
game_params held permanently by the midend and it will affect
subsequent game generations if they modify it. So now those arguments
are const, and all the games which previously modified their
game_params now take a copy and modify that instead.
[originally from svn r9830]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
do_recurse() now prunes early whenever it encounters a branch of the
search tree inconsistent with existing grid data (rather than the
previous naive approach of proceeding to enumerate all possibilities
anyway and then ruling them out one by one); do_recurse also tries to
split the row up into independent sections where possible; finally the
main solver loop (all three copies of which have now been factored out
into a new solve_puzzle function), instead of simply looping round and
round over all the rows and columns, heuristically looks at the ones
most changed since the last time deduction was attempted on them, on
the basis that that will probably yield the most information the
fastest.
[originally from svn r9828]
|
| |
|
|
|
|
|
|
| |
draw_numbers() was considerably confused between the width of the clue
border at the left and the height of the clue border at the top.
Unconfuse it (I think).
[originally from svn r9737]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
basically just so that it can divide mouse coordinates by the tile
size, but is definitely not expected to _write_ to it, and it hadn't
previously occurred to me that anyone might try. Therefore,
interpret_move() now gets a pointer to a _const_ game_drawstate
instead of a writable one.
All existing puzzles cope fine with this API change (as long as the
new const qualifier is also added to a couple of subfunctions to which
interpret_move delegates work), except for the just-committed Undead,
which somehow had ds->ascii and ui->ascii the wrong way round but is
otherwise unproblematic.
[originally from svn r9657]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that _ought_ to have it but did not.
I've tried to implement it before and found that the most obvious
approach was so effective as to constitute a spoiler, so this is a
deliberately weakened approach which in a bit of play-testing seems to
be a more sensible balance. It won't necessarily tell you at the very
instant you put a foot wrong, but it will at least ensure that (my
usual minimum standard) once you've filled in the whole grid you will
either have seen a victory flash, or an error indicator showing you
why not.
[originally from svn r9445]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
midend_status(), and given it three return codes for win, (permanent)
loss and game-still-in-play. Depending on what the front end wants to
use it for, it may find any or all of these three states worth
distinguishing from each other.
(I suppose a further enhancement might be to add _non_-permanent loss
as a fourth distinct status, to describe situations in which you can't
play further without pressing Undo but doing so is not completely
pointless. That might reasonably include dead-end situations in Same
Game and Pegs, and blown-self-up situations in Mines and Inertia.
However, I haven't done this at present.)
[originally from svn r9179]
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
[originally from svn r8914]
|
| |
|
|
|
|
|
|
|
|
| |
buttons in several games if STYLUS_BASED is defined: in games where
you can set a puzzle element to 'on', 'off' or 'not yet set', when
it's hard to mimic a second mouse button, it's better to have the
one 'button' cycle between all three states rather than from 'on'
back to 'unset'.
[originally from svn r8784]
|
| |
|
|
| |
[originally from svn r8605]
|
| |
|
|
| |
[originally from svn r8596]
|
| |
|
|
| |
[originally from svn r8435]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_conditionally_ able to format the current puzzle as text to be sent
to the clipboard. For instance, if a game were to support playing on
a square grid and on other kinds of grid such as hexagonal, then it
might reasonably feel that only the former could be sensibly
rendered in ASCII art; so it can now arrange for the "Copy" menu
item to be greyed out depending on the game_params.
To do this I've introduced a new backend function
(can_format_as_text_now()), and renamed the existing static backend
field "can_format_as_text" to "can_format_as_text_ever". The latter
will cause compile errors for anyone maintaining a third-party front
end; if any such person is reading this, I apologise to them for the
inconvenience, but I did do it deliberately so that they'd know to
update their front end.
As yet, no checked-in game actually uses this feature; all current
games can still either copy always or copy never.
[originally from svn r8161]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- missing static in filling.c
- better robustness in execute_move() in filling.c
- remove side effects in assert statements
- remove rogue diagnostic in galaxies.c
- remove // comment in map.c
- add more stylus-friendly UI to Pattern
- bias Unequal towards generating inequality clues rather than numeric
[originally from svn r7344]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
is mostly done with ifdefs in windows.c; so mkfiles.pl generates a
new makefile (Makefile.wce) and Recipe enables it, but it's hardly
any different from Makefile.vc apart from a few definitions at the
top of the files.
Currently the PocketPC build is not enabled in the build script, but
with any luck I'll be able to do so reasonably soon.
[originally from svn r7337]
|
| |
|
|
|
|
| |
fallback behaviour as PuTTY's support.
[originally from svn r7009]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
more general-purpose flags word for some time now. Rename it to
`flags'.
[originally from svn r6414]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
by a grep I just did. Oops.
[originally from svn r6113]
|
| |
|
|
|
|
|
|
|
|
|
|
| |
whether the timer is currently going is no longer solely dependent
on the current game_state: it can be dependent on more persistent
information stored in the game_ui. In particular, Mines now freezes
the timer permanently once you complete a grid for the first time,
so that you can then backtrack through your solution process without
destroying the information about how long it took you the first time
through.
[originally from svn r6088]
|
| |
|
|
|
|
|
|
|
|
|
| |
encode_params(). This is necessary for cases where generation-time parameters
that are normally omitted from descriptive IDs can place restrictions on other
parameters; in particular, when the default value of a relevant generation-time
parameter is not the one used to generate the descriptive ID, validation could
reject self-generated IDs (e.g., Net `5x2w:56182ae7c2', and some cases in
`Pegs').
[originally from svn r6068]
|
| |
|
|
|
|
|
|
|
|
|
| |
command-line programs (solosolver, patternsolver, mineobfusc) to be
built as part of the normal Makefiles. This means mkfiles.pl now has
the capability to compile a source file more than once with
different #defines. Also, fixes for those auxiliary programs and one
fix in midend.c which the Borland compiler objected to while I was
testing its makefile generation.
[originally from svn r6066]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
unpleasant and requiring lots of special cases to be taken care of
by every single game. The new interface exposes an integer `tile
size' or `scale' parameter to the midend and provides two much
simpler routines: one which computes the pixel window size given a
game_params and a tile size, and one which is given a tile size and
must set up a drawstate appropriately. All the rest of the
complexity is handled in the midend, mostly by binary search, so
grubby special cases only have to be dealt with once.
[originally from svn r6059]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint: because some front ends interpret `draw filled shape' to
mean `including its boundary' while others interpret it to mean `not
including its boundary' (and X seems to vacillate between the two
opinions as it moves around the shape!), you MUST NOT draw a filled
shape only. You can fill in one colour and outline in another, you
can fill or outline in the same colour, or you can just outline, but
just filling is a no-no.
This leads to a _lot_ of double calls to these functions, so I've
changed the interface. draw_circle() and draw_polygon() now each
take two colour arguments, a fill colour (which can be -1 for none)
and an outline colour (which must be valid). This should simplify
code in the game back ends, while also reducing the possibility for
coding error.
[originally from svn r6047]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- most game_size() functions now work in doubles internally and
round to nearest, meaning that they have less tendency to try to
alter a size they returned happily from a previous call
- couple of fiddly fixes (memory leaks, precautionary casts in
printf argument lists)
- midend_deserialise() now constructs an appropriate drawstate,
which I can't think how I overlooked myself since I _thought_ I
went through the entire midend structure field by field!
[originally from svn r6041]
|
| |
|
|
| |
[originally from svn r6031]
|
