diff options
| author | Ben Harris <bjh21@bjh21.me.uk> | 2023-08-08 09:35:06 +0100 |
|---|---|---|
| committer | Ben Harris <bjh21@bjh21.me.uk> | 2023-08-08 09:35:06 +0100 |
| commit | 78af0c821aa01f9e4a127b5b5f197fd1c8a22686 (patch) | |
| tree | d36f937230362ea31a08111eaa2b02dd2c317419 /misc.c | |
| parent | 6d4b20c413811a9f88e5be97128b7dd6445bff08 (diff) | |
| download | puzzles-78af0c821aa01f9e4a127b5b5f197fd1c8a22686.zip puzzles-78af0c821aa01f9e4a127b5b5f197fd1c8a22686.tar.gz puzzles-78af0c821aa01f9e4a127b5b5f197fd1c8a22686.tar.bz2 puzzles-78af0c821aa01f9e4a127b5b5f197fd1c8a22686.tar.xz | |
Guess: move hold marker upward by two pixels
This means that it now potentially overlaps the peg above it (part of
the current guess), rather than potentially overlapping the empty hole
below. More importantly, it means that the hold marker is erased by
the erasure of the rest of the peg area, so there's no need to
explicitly draw absent hold markers in the background colour. That in
turn means that absent hold markers don't nibble the tops off all the
pegs at some tile sizes.
Instead of this fix, I could have properly made the hold markers part
of the first row of empty holes, but that would have been rather
fiddly and I've long thought that the hold markers were too far from
the peg that they're holding.
I've also removed part of a comment about the drawing order of hold
markers that seems to have been obsolete even before this commit.
Diffstat (limited to 'misc.c')
0 files changed, 0 insertions, 0 deletions