aboutsummaryrefslogtreecommitdiff
path: root/guess.c (follow)
Commit message (Collapse)AuthorAge
...
* I've been pondering whether to do this for months: turn the ratherSimon Tatham2006-03-02
| | | | | | | | | | 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]
* 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]
* 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]
* 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]
* Another fix from Chris: Guess's allow-blanks mode wasn't allowingSimon Tatham2005-07-18
| | | | | | blanks... [originally from svn r6118]
* game_timing_state() now has access to the game_ui. This means thatSimon Tatham2005-07-10
| | | | | | | | | | | | 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]
* Some patches from James H:Simon Tatham2005-07-06
| | | | | | | | | | | | | | - 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]
* Add a `full' parameter to validate_params(), analogous to the one inJacob Nevins2005-07-05
| | | | | | | | | | | 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]
* Refactored the game_size() interface, which was getting reallySimon Tatham2005-07-05
| | | | | | | | | | | | | 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]
* draw_polygon() and draw_circle() have always had a portabilitySimon Tatham2005-07-03
| | | | | | | | | | | | | | | | | | | 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]
* Attempting to begin a drag from (i.e. just click on) the hint pegsSimon Tatham2005-06-30
| | | | | | | for a past guess caused strangeness up to and including segfault, thanks to bad bounds checking. Well spotted John Sullivan. [originally from svn r6040]
* When serialising this game, it's probably better to keep theSimon Tatham2005-06-29
| | | | | | half-finished guess in the game_ui rather than throwing it away. [originally from svn r6033]
* Make peg removal accessible from the keyboard.Jacob Nevins2005-06-28
| | | | [originally from svn r6032]
* New {en,de}code_ui functions should be static. Oops.Simon Tatham2005-06-28
| | | | [originally from svn r6031]
* More serialisation changes: the game_aux_info structure has now beenSimon Tatham2005-06-28
| | | | | | | | | | | | 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]
* Another function pair required for serialisation; these ones saveSimon Tatham2005-06-28
| | | | | | | | | | | 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]
* Re-architecting of the game backend interface. make_move() has beenSimon Tatham2005-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* Make the keyboard-control cursors visible whenever a keyboard control isJacob Nevins2005-06-25
| | | | | | activated. [originally from svn r6013]
* Couple of presets.Simon Tatham2005-06-24
| | | | [originally from svn r6011]
* More patches from James Harvey: enforce a maximum brightness in theSimon Tatham2005-06-24
| | | | | | | | | 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]
* Fix another display/UI glitch which triggered if you filled a rowSimon Tatham2005-06-24
| | | | | | | | (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]
* Turn off the keyboard-control cursor when the user reverts to mouseSimon Tatham2005-06-24
| | | | | | control. [originally from svn r6008]
* My background-erasing changes in r5996/r5997 caused trouble with theSimon Tatham2005-06-24
| | | | | | | | | | | | | | | 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]
* Array overflow fix from James Harvey.Simon Tatham2005-06-23
| | | | [originally from svn r6005]
* Make the `hold marker' in Guess accessible from the keyboard (`H' key, for wantJacob Nevins2005-06-23
| | | | | | of a better idea). [originally from svn r6004]
* Reinstate WinHelp topic now we have a manual chapter.Jacob Nevins2005-06-23
| | | | [originally from svn r6002]
* James Harvey's extensions to Guess: a couple of extra game settingsSimon Tatham2005-06-23
| | | | | | plus a manual chapter. [originally from svn r5999]
* Bah, not good enough. Extend those background erases by one moreSimon Tatham2005-06-23
| | | | | | pixel. [originally from svn r5997]
* Erase backgrounds when drawing over an existing circle, for theSimon Tatham2005-06-23
| | | | | | | 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]
* Allow dragging of coloured pegs from previous guesses. AlsoSimon Tatham2005-06-23
| | | | | | | | | | | | 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]
* Must outline as well as filling circles, because not all platformsSimon Tatham2005-06-23
| | | | | | can be guaranteed to draw bare filled shapes the same way. [originally from svn r5994]
* Two small fixes: add some ceil() calls to stop the puzzle shrinkingSimon Tatham2005-06-23
| | | | | | | every time I press N, and revert the help topic to NULL until some documentation materialises. [originally from svn r5993]
* `Guess', a Mastermind clone from James Harvey. This checkin alsoSimon Tatham2005-06-23
introduces a few new utility functions in misc.c, one of which is the bitmap obfuscator from Mines (which has therefore been moved out of mines.c). [originally from svn r5992]
generated by cgit v1.1 at 2026-05-13 23:29:11 +0000