This was only used for asking the stack if it is the one we are moving
cards from. We now have a better way to do that, by comparing against
`CardGame::moving_cards_source_stack()`, which doesn't require manually
telling a stack that it is/isn't focused.
Previously, dropping a card that overlapped multiple stacks that could
accept it, would always choose the stack that came first in the stacks
list, usually the leftmost one. This would feel very odd if the card
was only slightly overlapping the left stack, and 90% over the right
one. So now, we keep looking for closer stacks even once we've found a
valid one.
There may be an option that feels even better, based on the position of
the card being dragged and the card on top of the stack we're dropping
onto, but this already fixes the issue and feels very nice. :^)
Solitaire and Spider have almost identical code for dragging cards from
one stack to another, so it makes sense to move that here. But using
the term "moving" for them, instead of "focused" which (to me at least)
was not clear what it meant.
As part of this, made a const overload for `Card::rect()`. We need the
non-const one too as it's used for modifying the position of a card
that's being dragged. I plan on changing that soon but we'll see.
And while I'm at it, clarify the name of `associated_stack` to
`covered_stack`. It's used in exactly one way, so we can make the code
clearer by giving it a less generic name.
`create_standard_deck()` is the usual 52-card deck, but more custom
setups (such as Spider's multiples-of-one-suit) can be created by
passing suit counts to `create_deck()`.
This was giving wonky results with images that do not fill the entire
card - and it's also unnecessary, since the Buggie image we have been
using, and the two I will be adding, are all small enough to not need
scaling anyway. :^)
`CardPainter::set_background_image_path()` immediately repaints the card
back and inverted card back bitmaps if they exist, so users just need
to `update()` that part of the screen. This is handled automatically by
`CardGame`, but other users will have to do this manually.
Instead of each card being responsible for painting its own bitmaps, we
now have a CardPainter which is responsible for this. It paints a given
card the first time it is requested, and then re-uses that bitmap when
requested in the future. This saves memory for duplicate cards (such as
in Spider where several sets of the same suit are used) or unused ones
(for example, the inverted cards which are only used by Hearts). It
also means we don't throw away bitmaps and then re-create identical
ones when starting a new game.
We get some nice memory savings from this:
| | Before | After | Before (Virtual) | After (Virtual) |
|:----------|---------:|---------:|-----------------:|----------------:|
| Hearts | 12.2 MiB | 9.3 MiB | 25.1 MiB | 22.2 MiB |
| Spider | 12.1 MiB | 10.1 MiB | 29.2 MiB | 22.9 MiB |
| Solitaire | 16.4 MiB | 9.0 MiB | 25.0 MiB | 21.9 MiB |
All these measurements taken from x86_64 build, from a fresh launch of
each game after the animation has finished, but without making any
moves. The Hearts value will go up once inverted cards start being
requested.
Because `card->value() == 11` is a lot less clear than `card->rank() ==
Cards::Rank::Queen`, and also safer.
Put this, along with the `Suit` enum, in the `Cards` namespace directly
instead of inside `Cards::Card`. Slightly less typing that way.
For now, the only feature of this is that it sets the background colour
from the `Games::Cards::BackgroundColor` config value. Later, other
card game configuration and shared behaviour can go here, to save
duplicating it in each game.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
Playing cards have a `suit` such as `hearts`/`diamonds`, not a
`type`. Make the internal naming consistent with the way playing cards
are typically named.
`CharacterBitmap` instances are generated at run-time and put on the
heap, but they can be created in a `constexpr` context and stored in
static memory.
Also, remove additional `width` and `height` `static` values in favor
of using the `constexpr` member functions of `CharacterBitmap`.
These changes also include the removal of some initialization code
which tests if the `CharacterBitmap` is created since it is always
created and removes function-local `static` values which cause
run-time branches to ensure it is initialized each time the function
is called.
This isn't a complete conversion to ErrorOr<void>, but a good chunk.
The end goal here is to propagate buffer allocation failures to the
caller, and allow the use of TRY() with formatting functions.
This introduces a new MovementType concept to LibCards, starting the
process to allow other patience games to be implemented using it - that
differ more substantially from Klondike in logic.
This is currently used for two purposes: 1. to verify that the
'grabbed' stack of cards is valid* (sequential and correct colours) and
2. to allow 'grabbed' stacks to be pushed onto same-colour,
either-colour, or alternating-colour stacks
* Klondike doesn't need this logic, as per how the game works any
'grabbed' selection is guaranteed to be valid.
Now that the cards have rounded corners, draw the stack box behind the
cards with rounded corners as well. This way, the corner of the stack
box doesn't peek out from behind the cards.
The caveat here is that the "play" card stack now needs to hold a
reference to the "waste" stack beneath it so it knows when not to draw
its background on top of the waste stack. To faciliate that, the array
of card stacks is now a NonnullRefPtrVector so the play stack can store
a smart pointer to the waste stack (instead of a raw pointer or
reference).
