With this patch you can use right-click to mark a square on the board.
You can add modifier keys to the click to change to alternate color
(with CTRL) or secondary color (with Shift). If you right-click and
drag from one square to another you will create an arrow. The
markings go away as soon as you left-click on the board or the board
state changes.
Note: The arrows sometimes look weird, and horizontal ones get cut
off. They also don't account for alpha. This is not a bug in
Chess code, rather, likely in the fill_path() function that's
used to draw the arrows. If anyone might know what's up with
that I urge you to take a look. :)
This patch allows the user to load games using PGN files. The parsing
is not complete and has a bunch of work left to be done, but it's
okay for our use case here. It can load all of the games our PGN
exporter can save. As the Chess program impoves so can the PGN parser.
This patch allows the user to go back and forward in move history
to replay moves from the game. This is view-only however, and as soon
as a move is made the board returns to it's current state. This will
work well for replaying games loaded in with PGN files, once that's
implemented.
You can now copy the board state as Forsyth-Edwards Notation. You can
then paste this into other chess programs/games, or into ours when
it gets implemented.
This patch adds an option to the menubar for exporting the current
game as a PGN file. This file can then be read by other chess
programs (and ours eventually) to replay the game or analyze it.
The implementation is mostly PGN spec compliant, however the code
could use some more work. Particularly the `const_cast`s...
But it's a start. :^)
Fixup: Chess: Fixed hard-coded home path in unveil() call
Fixup: Chess: Removed castling flags from Move struct
The castling detection logic is done inside Move::to_algebraic()
now, removing the need for is_castle_short and is_castle_long flags
inside of the Move struct.
As much as I like the "test" piece set, I think "stelar7" is a much
better first impression for anyone opening the Chess game, so I
consider it a much more sensible default.
This makes the game less deterministic and more fun. The "physics"
definitely feel a little goofy, and I'm sure they can be greatly
improved, but still it's already better. :^)
The qualified name of a font is "<Family> <Size> <Weight>". You can
get the QN of a Font via the Font::qualified_name() API, and you can
get any system font by QN from the GUI::FontDatabase. :^)
From https://youtu.be/YNSAZIW3EM0?t=1474:
"Hmm... I don't think that name is right! From the perspective of
userspace, this is a file descriptor. File description is what the
kernel internally keeps track of, but as far as userspace is concerned,
he just has a file descriptor. [...] Maybe that name should be changed."
Core::File even has a member of this enum type... called
m_should_close_file_descriptor - so let's just rename it :^)
Before, we had about these occurrence counts:
COPY: 13 without, 33 with
MOVE: 12 without, 28 with
Clearly, 'with' was the preferred way. However, this introduced double-semicolons
all over the place, and caused some warnings to trigger.
This patch *forces* the usage of a semi-colon when calling the macro,
by removing the semi-colon within the macro. (And thus also gets rid
of the double-semicolon.)
This adds a "settings" option that allows the user to configure the
board size and target tile, and optionally save them to a config file.
Closes#3219.
See how straightforward this was? That's because, thanks to the separation
between the model and the view, we can tweak the view without modifying the
model in any way.
Look Ali, it's simple:
* The *model* (in many cases, an instance of GUI::Model, but it doesn't have to
be) should implement the "business logic" (in this case, game logic) and
should not concern itself with how the data/state is displayed to the user.
* The *view*, conversely, should interact with the user (display data/state,
accept input) and should not concern itself with the logic. As an example, a
GUI::Button can display some text and accept clicks -- it doesn't know or care
what that text *means*, or how that click affects the app state. All it does
is it gets its text from *somebody* and notifies *somebody* of clicks.
* The *controller* connects the model to the view, and acts as "glue" between
them.
You could connect *several different* views to one model (see FileManager), or
use identical views with different models (e.g. a table view can display pretty
much anything, depending on what model you connect to it).
In this case, the model is the Game class, which maintains a board and
implements the rules of 2048, including tracking the score. It does not display
anything, and it does not concern itself with undo management. The view is the
BoardView class, which displays a board and accepts keyboard input, but doesn't
know how exactly the tiles move or merge -- all it gets is a board state, ready
to be displayed. The controller is our main(), which connects the two classes
and bridges between their APIs. It also implements undo management, by basically
making straight-up copies of the game.
Isn't this lovely?
This makes the game look closer to the original.
It also fixes a weird thing where cells were displayed in a wrong order (as if
mirrored or something), and to accommodate for that keyboard actions were also
mixed up. Now it's all working as intended.
