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.
Pressing H now suggests the lexicographically first row consistent
with all previous feedback.
The previous function of the H key to toggle a hold marker on the
current peg is now performed by Space / CURSOR_SELECT2, which is more
in line with other puzzles anyway.
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]
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]
the background under a Guess coloured peg in mid-drag. Currently it
assumes the circle doesn't extend into the next pixel, which the docs
for draw_circle warn might happen due to antialiasing.
[originally from svn r9450]
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]
thereafter read. Most of these changes are just removal of pointless
stuff or trivial reorganisations; one change is actually substantive,
and fixes a bug in Keen's clue selection (the variable 'bad' was
unreferenced not because I shouldn't have set it, but because I
_should_ have referenced it!).
[originally from svn r9164]
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]
actual behaviour change: Untangle now permits dragging with the
right mouse button, which has exactly the same effect as it does
with the left. (Harmless on desktop platforms, but helpful when
"right-click" is achieved by press-and-hold; now the drag takes
place even if you hesitate first.)
[originally from svn r8177]
_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]
Labels are toggled on and off by pressing L (just like Map). Might
help colour-blind users, and might also make it easier to describe
game positions to other people because `abbc' has fewer syllables
than `red, yellow, yellow, green', and hugely fewer letters if
you're typing it.
[originally from svn r6916]
Fix it, add holds to the undo history (by analogy with Net), and save the
current holds in saved games.
Also fix a couple of unrelated minor issues with string encoding.
[originally from svn r6590]
washed-out yellow and green in Guess into their full-brightness pure
forms. This makes them hard to see against some backgrounds, so I'm
also surrounding all coloured pegs with black outlines. Looks a
little cartoony, but I think it's an overall improvement on the
previous look.
[originally from svn r6589]
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]
to call game_set_size() twice on the same drawstate. Finally, a
definite decision: it isn't. Accordingly, midend.c arranges never to
do so, the devel docs state that puzzles may enforce by assertion
that it never happens, and the four puzzles which care (i.e. use
blitters) do so.
[originally from svn r6274]
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]
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]
- reinstate the initialisation of ds->w and ds->h in guess.c, which
I'd accidentally removed during game_size() refactoring
- reorganise Net's interpret_move() so that my uncommitted patch
for drag-based UI (which he uses on the Palm port) will apply
more easily
- the interpret_move() changes make it easy to have a single move
type which rotates a tile by 180 degrees, so this is now provided
via the `F' key (but there's no spare button available to provide
it via the mouse).
[originally from svn r6070]
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]
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]
for a past guess caused strangeness up to and including segfault,
thanks to bad bounds checking. Well spotted John Sullivan.
[originally from svn r6040]
retired, and replaced with a simple string. Most of the games which
use it simply encode the string in the same way that the Solve move
will also be encoded, i.e. solve_game() simply returns
dupstr(aux_info). Again, this is a better approach than writing
separate game_aux_info serialise/deserialise functions because doing
it this way is self-testing (the strings are created and parsed
during the course of any Solve operation at all).
[originally from svn r6029]
and restore anything vitally important in the game_ui. Most of the
game_ui is expected to be stuff about cursor positions and currently
active mouse drags, so it absolutely _doesn't_ want to be preserved
over a serialisation; but one or two things would be disorienting or
outright wrong to reset, such as the Net origin position and the
Mines death counter.
[originally from svn r6026]
split into two functions. The first, interpret_move(), takes all the
arguments that make_move() used to get and may have the usual side
effects of modifying the game_ui, but instead of returning a
modified game_state it instead returns a string description of the
move to be made. This string description is then passed to a second
function, execute_move(), together with an input game_state, which
is responsible for actually producing the new state. (solve_game()
also returns a string to be passed to execute_move().)
The point of this is to work towards being able to serialise the
whole of a game midend into a byte stream such as a disk file, which
will eventually support save and load functions in the desktop
puzzles, as well as restoring half-finished games after a quit and
restart in James Harvey's Palm port. Making each game supply a
convert-to-string function for its game_state format would have been
an unreliable way to do this, since those functions would not have
been used in normal play, so they'd only have been tested when you
actually tried to save and load - a recipe for latent bugs if ever I
heard one. This way, you won't even be able to _make_ a move if
execute_move() doesn't work properly, which means that if you can
play a game at all I can have pretty high confidence that
serialising it will work first time.
This is only the groundwork; there will be more checkins to come on
this theme. But the major upheaval should now be done, and as far as
I can tell everything's still working normally.
[originally from svn r6024]
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]
