| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
[originally from svn r4182]
|
| |
|
|
| |
[originally from svn r4174]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
the tetrahedron, octahedron and icosahedron.
[originally from svn r4151]
|
| |
|
|
|
|
| |
configuration is absent as yet.
[originally from svn r4145]
|
| |
|
|
|
|
| |
GTK code, rudiments of event passing.
[originally from svn r4141]
|
|
|
games.
[originally from svn r4138]
|
