aboutsummaryrefslogtreecommitdiff
path: root/blackbox.c (follow)
Commit message (Collapse)AuthorAge
* Minor bug fixes from James Harvey.Simon Tatham2009-12-17
| | | | [originally from svn r8785]
* Keyboard control patch for Black Box, from James H.Simon Tatham2009-01-28
| | | | [originally from svn r8439]
* 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]
* Dariusz Olszewski's changes to support compiling for PocketPC. ThisSimon Tatham2007-02-26
| | | | | | | | | | | | 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]
* HTML Help support for Puzzles, with the same kind of automaticSimon Tatham2006-12-24
| | | | | | fallback behaviour as PuTTY's support. [originally from svn r7009]
* Tal Kelrich spotted that hitting `Solve' on a configuration which isSimon Tatham2006-02-07
| | | | | | | | | laser-indistinguishable from the right solution _but_ has a number of balls outside the acceptable range does not report an error. His example was the game ID w8h8m5M5:1e3e6e80fa3e16265ccef7ca , omitting the rightmost ball in the second row. [originally from svn r6542]
* Cleanup: it was absolutely stupid for game_wants_statusbar() to be aSimon Tatham2005-10-22
| | | | | | | | | 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]
* 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]
* 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]
* Cleanups to completion flashes: all four of these games used toSimon Tatham2005-08-05
| | | | | | | | | redraw the whole window _every_ time game_redraw() was called during a flash. Now they only redraw the whole window every time the background colour actually changes. Thanks to James H for much of the work. [originally from svn r6166]
* Cleanups from James H: a few missing statics, a precautionary castSimon Tatham2005-08-03
| | | | | | | | | or two, a debugging fix, a couple of explicit initialisations of variables that were previously read uninitialised, and a fix for a whopping great big memory leak in Slant owing to me having completely forgotten to write free_game(). [originally from svn r6159]
* New end-game approach to Black Box. Instead of revealing the ballSimon Tatham2005-07-31
| | | | | | | | | | | positions immediately when you make an error, the game now reveals as little information as is necessary to prove you wrong (including none - if an existing laser path you know about is inconsistent with your guesses, the game will just point it out and tell you nothing new!) and you can try again. Errors are counted in much the same way as deaths in Mines. [originally from svn r6152]
* One more fix from Ben H. Also switched round the arena colourSimon Tatham2005-07-29
| | | | | | | | | | | selection in the redraw function, so that locked squares are no longer displayed once the game is at an end. (It looked untidy and disorienting for lighter-coloured locked squares to suddenly become darker when the box was opened. You can still flip back and forth to your previous game state using undo/redo if you want to compare the results against your lock pattern.) [originally from svn r6150]
* Various fixes and cleanups suggested by Ben Hutchings:Simon Tatham2005-07-29
| | | | | | | | | | | | | | | | | - clarified wording of messages in validate_params(), including in particular a correction from `< 255' to `<= 255' - fixed random_upto() in game generation which caused the maximum number of balls never to be used when there was uncertainty - fixed widespread miscalculation of rectangular-array indices (multiplication by h instead of w, which would have broken non-square grids rather profoundly) - corrected an ANSI namespace violation - removed real functionality from the inside of assert() statements, so that the game should still work when compiled -DNDEBUG - couple of unnecessary linear-time loops removed. [originally from svn r6149]
* Bah, there's always one: failed to `svn add' blackbox.c itself!Simon Tatham2005-07-17
[originally from svn r6101]