aboutsummaryrefslogtreecommitdiff
path: root/devel.but (follow)
Commit message (Collapse)AuthorAge
* New rule: interpret_move() is passed a pointer to the game_drawstateSimon Tatham2012-09-09
| | | | | | | | | | | | | | | | 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]
* Patch from Jonas Koelker for the developer docs, fixing a couple ofSimon Tatham2012-05-14
| | | | | | | editing errors and adding some comments about the necessary order of midend operations called by a front end. [originally from svn r9533]
* Changed my mind about midend_is_solved: I've now reprototyped it asSimon Tatham2011-06-19
| | | | | | | | | | | | | | | | 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]
* Trivial markup fix.Simon Tatham2011-04-03
| | | | [originally from svn r9144]
* Move up midend_is_solved() in the developer docs from subheading toSimon Tatham2011-04-03
| | | | | | | | heading level. It's _almost_ apt to have it as a subheading of midend_solve(), but not quite, and it certainly wasn't intentional - I must have absentmindedly typed the wrong Halibut command letter. [originally from svn r9142]
* Add a function to every game backend which indicates whether a gameSimon Tatham2011-04-02
| | | | | | | | | | | 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]
* Add functions provided by the midend to tell a front end whether GUISimon Tatham2011-04-02
| | | | | | buttons for undo and redo should currently be greyed out. [originally from svn r9139]
* Patch from Mark Wooding to add documentation of the newSimon Tatham2010-05-29
| | | | | | | 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]
* Introduce, and implement as usefully as I can in all front ends, aSimon Tatham2009-12-27
| | | | | | | | | | new function in the drawing API which permits the display of text from outside basic ASCII. A fallback mechanism is provided so that puzzles can give a list of strings they'd like to display in order of preference and the system will return the best one it can manage; puzzles are required to cope with ASCII-only front ends. [originally from svn r8793]
* Fix duplicate keyword.Jacob Nevins2009-02-22
| | | | [originally from svn r8458]
* Introduce some infrastructure to permit games' print functions toSimon Tatham2009-02-22
| | | | | | draw dotted lines. No puzzle yet uses this, but one's about to. [originally from svn r8453]
* r8396 introduced midend_tilesize(). Document it.Simon Tatham2009-01-16
| | | | | [originally from svn r8415] [r8396 == 7888d8db677e25d2401914e6aacb1be02301d15f]
* Remove strange punctuation.Jacob Nevins2008-10-04
| | | | [originally from svn r8199]
* New infrastructure feature. Games are now permitted to beSimon Tatham2008-09-06
| | | | | | | | | | | | | | | | | | | | | | _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]
* Just noticed that the return value of midend_process_key() wasn'tSimon Tatham2008-06-10
| | | | | | documented. [originally from svn r8062]
* New feature in midend.c which allows us to ask for the number of theSimon Tatham2008-04-08
| | | | | | | | | | currently selected preset, if any. I've used this in the GTK front end to have the Type menu mark the currently selected menu item. (After considerable beating of GTK with sticks, I might add. Grr.) Currently the same UI feature is not yet supported on Windows or MacOS, but I hope to do those too at some point if it's feasible. [originally from svn r7980]
* Revise the printing colour framework so that we can explicitlySimon Tatham2008-04-07
| | | | | | | request either of hatching or halftoning, and also choose which to supply as a fallback when printing in colour. [originally from svn r7976]
* Since we've changed the semantics of the `expand' argument to midend_size(),Jacob Nevins2007-03-03
| | | | | | change the name. Also document the new semantics. [originally from svn r7369]
* About time I got round to documenting the newSimon Tatham2007-03-03
| | | | | | REQUIRE_{RBUTTON,NUMPAD} flags. [originally from svn r7356]
* Misdirected cross-reference spotted by Jonas Koelker.Simon Tatham2007-01-27
| | | | [originally from svn r7172]
* Couple of minor errors.Simon Tatham2006-10-17
| | | | [originally from svn r6872]
* I'm sick of repeatedly adding and removing local changes to RecipeSimon Tatham2006-08-05
| | | | | | | | | | | | | | | | | | | | | | when testing a new game, so here's a new architecture for the Recipe file. mkfiles.pl now supports several new features: - an `!include' directive, which accepts wildcards - += to append to an existing object group definition - the ability to divert output to an arbitrary file. So now each puzzle has a `.R' file containing a fragment of Recipe code describing that puzzle, and the central Recipe does `!include *.R' to construct the Makefiles. That way, I can keep as many experimental half-finished puzzles lying around my working directory as I like, and I won't have to keep reverting Recipe when I check in any other changes. As part of this change, list.c is no longer a version-controlled file; it's now constructed by mkfiles.pl, so that it too can take advantage of this mechanism. [originally from svn r6781]
* Random docs cleanups I've collected together.Simon Tatham2006-07-07
| | | | [originally from svn r6749]
* Cleanup: relieve frontends of the duty to callSimon Tatham2005-10-22
| | | | | | | | | | | | | midend_rewrite_statusbar() and check the result against the last string returned. This is now done centrally in drawing.c, and the front end status bar function need only do what it says on the tin. While I'm modifying the prototype of drawing_init(), I've also renamed it drawing_new() for the same reason as random_new() (it _allocates_ a drawing object, rather than just initialising one passed in). [originally from svn r6420]
* Forgot to update devel.but in r6417.Simon Tatham2005-10-22
| | | | | [originally from svn r6418] [r6417 == eb2013efc0a6201d0e46de65c1a905b676d13d01]
* Cleanup: remove the game_state parameter to game_colours(). No gameSimon Tatham2005-10-22
| | | | | | | | | | | | 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]
* Cleanup: the `mouse_priorities' field in the back end has been aSimon Tatham2005-10-22
| | | | | | | more general-purpose flags word for some time now. Rename it to `flags'. [originally from svn r6414]
* Cleanup: rename random_init() to random_new(), because it actuallySimon Tatham2005-10-22
| | | | | | | _allocates_ a random_state rather than just initialising one passed in by the caller. [originally from svn r6412]
* I've dithered a bit in the past about whether or not it's allowableSimon Tatham2005-09-05
| | | | | | | | | | 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]
* Couple of minor updates to restore accuracy.Simon Tatham2005-09-04
| | | | [originally from svn r6268]
* Native Windows printing support, using the infrastructure I put inSimon Tatham2005-08-20
| | | | | | | | | | | | | | | | | | | | | 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]
* Richard B points out a cut and paste error.Simon Tatham2005-08-19
| | | | [originally from svn r6192]
* Substantial infrastructure upheaval. I've separated the drawing APISimon Tatham2005-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* Slant uses the same generation strategy as Solo, despite not havingSimon Tatham2005-08-03
| | | | | | | | | 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]
* Various cleanups and clarifications to devel.but; some from RichardSimon Tatham2005-08-01
| | | | | | | | | 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]
* missing `i' in `\e'Jacob Nevins2005-07-29
| | | | [originally from svn r6151]
* Tweak a paragraph after discussion with Simon.Jacob Nevins2005-07-29
| | | | [originally from svn r6144]
* Shiny new developer documentation to replace the old sketchy HACKINGSimon Tatham2005-07-28
guide. [originally from svn r6142]
generated by cgit v1.1 at 2026-05-21 13:15:52 +0000