aboutsummaryrefslogtreecommitdiff
path: root/midend.c (follow)
Commit message (Collapse)AuthorAge
...
* If you paste in a random seed with different ephemeral parametersSimon Tatham2005-05-18
| | | | | | | | | | from the currently configured ones, and then bring the Random Seed box back up, the wrong parameters get shown, and the resulting random seed is incorrect for the current game. At least, it was, until this checkin. [originally from svn r5808]
* It's a good idea to validate presets received from the environment.Simon Tatham2005-05-18
| | | | [originally from svn r5805]
* Move the colour configuration into midend.c so that it becomesSimon Tatham2005-05-18
| | | | | | | | | | cross-platform, and rename the environment variables so that they follow the puzzle name. Should allow a static environment configuration for each puzzle. Also introduced a <game>_PRESETS variable for people whose favourite configuration isn't on the Type menu by default. [originally from svn r5801]
* After much thought, I've decided that `Restart' on r is not aSimon Tatham2005-05-17
| | | | | | | | particularly useful keypress, particularly given how easy it is to confuse it with `Redo'. So both r and ^R are now Redo, and Restart is relegated to being a menu-only option. [originally from svn r5796]
* `Restart' is now an undo-able action: it appends a move to the endSimon Tatham2005-05-17
| | | | | | | | | | | | | | | | | | | | of the undo list rather than destroying it. Partly this is because accidental restarts are a real pain, and partly because it allows you to compare the initial to the current state by restart-then-undo which is handy in some puzzles. In order to do this, I've introduced an additional per-entry field in the undo list in the midend, which tracks which states were created by `unusual' operations (Solve and Restart). The midend takes care of suppressing animation and completion flashes during transitions between a `special' state and its predecessor, relieving the game backends of having to do it individually. (This probably means I could remove some complexity in the flash_time() functions in most backends, but I haven't done that in this checkin.) [originally from svn r5791]
* comment c'n'p errorJacob Nevins2005-05-17
| | | | [originally from svn r5790]
* The game IDs for Net (and Netslide) have always been random seedsSimon Tatham2005-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | rather than literal grid descriptions, which has always faintly annoyed me because it makes it impossible to type in a grid from another source. However, Gareth pointed out that short random-seed game descriptions are useful, because you can read one out to someone else without having to master the technology of cross- machine cut and paste, or you can have two people enter the same random seed simultaneously in order to race against each other to complete the same puzzle. So both types of game ID seem to have their uses. Therefore, here's a reorganisation of the whole game ID concept. There are now two types of game ID: one has a parameter string then a hash then a piece of arbitrary random seed text, and the other has a parameter string then a colon then a literal game description. For most games, the latter is identical to the game IDs that were previously valid; for Net and Netslide, old game IDs must be translated into new ones by turning the colon into a hash, and there's a new descriptive game ID format. Random seed IDs are not guaranteed to be portable between software versions (this is a major reason why I added version reporting yesterday). Descriptive game IDs have a longer lifespan. As an added bonus, I've removed the sections of documentation dealing with game parameter encodings not shown in the game ID (Rectangles expansion factor, Solo symmetry and difficulty settings etc), because _all_ parameters must be specified in a random seed ID and therefore users can easily find out the appropriate parameter string for any settings they have configured. [originally from svn r5788]
* Added an automatic `Solve' feature to most games. This is useful forSimon Tatham2005-05-02
| | | | | | | | | | | | | | | | various things: - if you haven't fully understood what a game is about, it gives you an immediate example of a puzzle plus its solution so you can understand it - in some games it's useful to compare your solution with the real one and see where you made a mistake - in the rearrangement games (Fifteen, Sixteen, Twiddle) it's handy to be able to get your hands on a pristine grid quickly so you can practise or experiment with manoeuvres on it - it provides a good way of debugging the games if you think you've encountered an unsolvable grid! [originally from svn r5731]
* Introduce the concept of a `game_aux_info' structure. This isSimon Tatham2005-05-02
| | | | | | | | | | constructed at the same time as an internally generated game seed, so that it can preserve any interesting information known by the program at generation time but not physically contained within the text of the game seed itself. (Such as, for example, the solution.) Currently not used for anything yet, but it will be. [originally from svn r5729]
* Introduced a new function in every game which formats a game_stateSimon Tatham2005-05-01
| | | | | | | | as text. This is used by front ends to implement copy-to-clipboard. Currently the function does nothing (and is disabled) in every game except Solo, but it's a start. [originally from svn r5724]
* Sanitising the mouse input data was a good idea, but mySimon Tatham2005-01-25
| | | | | | implementation sucked. Revise it completely. [originally from svn r5209]
* Include code in midend.c to sanitise streams of mouse events so thatSimon Tatham2005-01-25
| | | | | | | | | | | back ends can be assured of always receiving them in a sensible sequence (button-down, followed by zero or more drags, followed by button-up, and never changing button in the middle of such a sequence). I have a suspicion this issue was the cause of the mysterious Pattern grid updates seen by Dan during testing last night. [originally from svn r5208]
* Rather than each game backend file exporting a whole load ofSimon Tatham2005-01-17
| | | | | | | | | | functions and a couple of variables, now each one exports a single structure containing a load of function pointers and said variables. This should make it easy to support platforms on which it's sensible to compile all the puzzles into a single monolithic application. The two existing platforms are still one-binary-per-game. [originally from svn r5126]
* Add a `jumble' key (`J') to Net, which scrambles the positions of all unlockedJacob Nevins2004-12-22
| | | | | | | | | | tiles randomly. (Rachel asked for this; it's been being tested for a good few months now, and Simon didn't care either way, so in it goes :) As part of this, the front end can now be asked to provide a random random seed (IYSWIM). [originally from svn r5019]
* After discussion with Simon, the game redraw functions are now passed a newJacob Nevins2004-08-16
| | | | | | | | | argument `dir' which tells them whether this redraw is due to an undo, rather than have them second-guess it from game state. Note that none of the actual games yet take advantage of this; so it hasn't been tested in anger (although it has been inspected by debugging). [originally from svn r4469]
* Now that we have string-encodable game parameters, let's support aSimon Tatham2004-05-20
| | | | | | | command-line argument which is either a set of parameters or a params+seed game ID. [originally from svn r4234]
* Introduce routines in each game module to encode a set of gameSimon Tatham2004-05-19
| | | | | | | | | | | | parameters as a string, and decode it again. This is used in midend.c to prepend the game parameters to the game seed, so that copying out of the Specific box is sufficient to completely specify the game you were playing. Throughout development of these games I have referred to `seed' internally, and `game ID' externally. Now there's a measurable difference between them! :-) [originally from svn r4231]
* Don't rush move animation to a conclusion on a subsequent keypressSimon Tatham2004-05-11
| | | | | | | | unless there's actual activity happening as a result of the move. Net animations were tending to get rushed to conclusion by the mouse button release now that it's being reported to the mid-end. [originally from svn r4211]
* Framework alteration: we now support a `game_ui' structure inSimon Tatham2004-05-11
| | | | | | | | | | | | | addition to the `game_state'. The new structure is intended to contain ephemeral data pertaining to the game's user interface rather than the actual game: things stored in the UI structure are not restored in an Undo, for example. make_move() is passed the UI to modify as it wishes; it is now allowed to return the _same_ game_state it was passed, to indicate that although no move has been made there has been a UI operation requiring a redraw. [originally from svn r4207]
* The Windows RNG turns out to only give about 16 bits at a time. ThisSimon Tatham2004-05-03
| | | | | | | | | | | | | | | is (a) pretty feeble, and (b) means that although Net seeds transfer between platforms and still generate the same game, there's a suspicious discrepancy in the typical seed _generated_ by each platform. I have a better RNG kicking around in this code base already, so I'll just use it. Each midend has its own random_state, which it passes to new_game_seed() as required. A handy consequence of this is that initial seed data is now passed to midend_new(), which means that new platform implementors are unlikely to forget to seed the RNG because failure to do so causes a compile error! [originally from svn r4187]
* Implement selection of game seeds, by reusing the config boxSimon Tatham2004-05-03
| | | | | | | | | mechanism I've just invented (the midend handles the standard game selection configuration). Each game is now required to validate its own seed data before attempting to base a game on it and potentially confusing itself. [originally from svn r4186]
* Configuration dialog box, on the GTK front end only as yet.Simon Tatham2004-05-01
| | | | [originally from svn r4182]
* Added a status bar.Simon Tatham2004-04-29
| | | | [originally from svn r4174]
* Add a new game concept called a `flash'. This is a graphical effectSimon Tatham2004-04-28
| | | | | | | | | | | | | | | taking non-zero time, which is triggered by the making of a move and is _not_ hurried to its conclusion by the start of the next move (so the game redraw function is expected to be able to draw it in parallel with continuing moves). The only thing that prematurely terminates a flash is the start of a fresh flash. In particular, this concept is used to display the completion flash in Net, because at least _my_ playing instincts make me lock every piece I've unambiguously placed, and hence the last turn move is instantly followed by a lock move which was previously suppressing the completion flash. [originally from svn r4168]
* Add a menu bar, in both Windows and GTK. In particular, game modulesSimon Tatham2004-04-28
| | | | | | | | | are now expected to provide a list of `presets' (game_params plus a name) which are selectable from the menu. This means I can play both Octahedron and Cube without recompiling in between :-) While I'm here, also enabled a Cygwin makefile, which Just Worked. [originally from svn r4158]
* Implemented Cube, in a sufficiently general way that it also handlesSimon Tatham2004-04-27
| | | | | | the tetrahedron, octahedron and icosahedron. [originally from svn r4151]
* Further general development. Net is now playable, thoughSimon Tatham2004-04-26
| | | | | | configuration is absent as yet. [originally from svn r4145]
* General further development. Sketched out the mid-end, added moreSimon Tatham2004-04-25
| | | | | | GTK code, rudiments of event passing. [originally from svn r4141]
* Initial checkin of a portable framework for writing small GUI puzzleSimon Tatham2004-04-25
games. [originally from svn r4138]
generated by cgit v1.1 at 2026-05-04 19:40:02 +0000