aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Use a dynamically-sized buffer for Pattern row cluesBen Harris2023-01-02
|
* Add a macro of an upper bound on the formatted length of an integerBen Harris2023-01-02
| | | | | | | | | There are lots of places where Puzzles formats integers into fixed-length buffers using sprintf() with a "%d" format. This isn't very safe, since C doesn't guarantee any particular maximum size for an "int". However, the restrictions on representations of integers means we can infer an upper bound using sizeof(), CHAR_BIT, and an approximation to the binary log of 10.
* Adjust font size of Pattern clues based on the numbersBen Harris2023-01-02
| | | | | | | If all the column clues are single digits, then the font can be larger without adjacent clues getting too close to each other. I've also slightly increased the font size even with two-digit clues, from TILE_SIZE/2 to TILE_SIZE/1.8.
* Pattern: Pack clues for each row more closely togetherBen Harris2023-01-01
| | | | | | | | | | | Rather than centring each clue in an imaginary box, put equal amounts of space between them (using space characters) and then right-align the whole string. This makes for more efficient use of space, and I think it also looks better when there are two-digit clues. This does introduce a rather grotty (if large) fixed-size buffer for row clues. Probably the row clues should be pre-formatted into a string when the puzzle is set up.
* Pattern: Clip clues to their proper rectanglesBen Harris2023-01-01
| | | | | | | | | | | | | | Since the drawing API offers no guarantees about where text drawing might have effects, it's unsafe to erase text other than by wiping the clipping rectangle that was in effect when it was drawn. In practice, this means that all variable (including colour) text should be drawn with a narrow clipping rectangle. It wasn't actually a practical problem that Pattern didn't clip its clues, but I'll like to make its fonts less tiny, which will make it more likely to need clipping in odd cases. This also factors out some repeated computations in draw_numbers().
* Create an icon for the Null GameBen Harris2022-12-31
| | | | | | This might be useful for creating a KaiOS app of it. It also conveniently ensures that Null Game doesn't just build but also runs correctly.
* Support the generation of icons from uniformly-coloured screenshotsBen Harris2022-12-31
| | | | | | | The square.pl script removed all pixels that were the same colour as the edge ones, even if that meant removing all of the pixels. Now it stops removing pixels at 1x1 so that there will be something left for ImageMagick to work on.
* Don't use Null Game's extra source files for all GUI programsBen Harris2022-12-31
| | | | | | | | | | | | | All the not-quite-puzzle GUI programs (only galaxieseditor at this point) were using the extra source files from Null Game, presumably as a convenient way of asking not to have an icon on platforms where icons are provided as extra source files. Unfortunately, this all went wrong if Null Game did have a save file for an icon, causing CMake to complain about multiple definitions of a target. Now these programs look for extra files under their own names, which will work just as well since those have no save files to generate icons from either.
* devel.but: fix markup error causing build failure.Simon Tatham2022-12-31
|
* Slightly better macro usage for Tracks completion flashBen Harris2022-12-30
|
* Clear any existing Tracks flash data when generating itBen Harris2022-12-30
| | | | | | | | | | Simon points out that if you have an ambiguous puzzle then it might need different flash data for different solutions, so if you solve it one way, than manually unsolve it and solve it another way, the old flash data in the game state need to be cleared out when the new flash data are written. Tested by solving the hugely ambiguous "5x5:CwC,5,5,5,5,S5,S5,5,5,5,5".
* Tracks: Set the grid colour based on othersBen Harris2022-12-29
| | | | | | | | | | | COL_GRID used to be mid-way between the usual COL_BACKGROUND and COL_TRACK_BACKGROUND. But then I changed mkhighlight() so that it didn't make COL_BACKGROUND so dark and that made the grid lines indistinguishable from the track background. Now COL_GRID is generated from COL_BACKGROUND and COL_TRACK_BACKGROUND so as long as those are sufficiently distinct from each other, COL_GRID will be distinct from both of them.
* Expose colour_mix() to backends (and others)Ben Harris2022-12-29
| | | | | | | | Quite a few backends currently generate colours by multiplying the foreground colour by a fraction, effectively mixing it with black. On a black background, this might be reasonably replaced by mixing the background colour with white, but that's rather arithmetically fiddly. Happily, I already have a function for that and just need to expose it.
* Fancier completion flash for TracksBen Harris2022-12-27
| | | | | | It now runs along the track from A to B, spending the first half of FLASH_TIME lighting all the segments and the second half extinguishing them.
* Tracks: Highlight more counting errors if track looks goodBen Harris2022-12-27
| | | | | | | | | | | | | | | | | Normally, Tracks puts error marks on row and column clues only when one of the existing track or no-track marks will have to be removed to satisfy the clue. This could lead to a situation where the player had built a track from A to B and got neither a win nor a highlighted error because the only error was in a row or column having too few track segments. This commit re-arranges the completion checking so that if there's a complete track from A to B and no spurious track then the game will highlight any clue that isn't matched by the actually laid track. This should mean that any solution with a track from A to B will either be a win or have a highlighted error. This should fix Android issue #266.
* When filling in or blanking a square, don't generate null movesBen Harris2022-12-27
| | | | | | | | | | | | | | | | This applies to various square-filling games: Keen, Solo, Towers, Undead, and Unequal. In all cases, selecting a square and pressing the number that was already in it, or selecting an empty square and pressing Backspace, would add a move to the undo chain that did nothing. This also meant that the convention where Backspace from the top level of an application in KaiOS leaves the application didn't work. Now the various interpret_move() functions check the current state of the grid, and return NULL or UI_UPDATE where a move wouldn't change the board. UI_UPDATE is returned in the case where the cursor was put in place using the mouse, because in those cases I think the cursor should still be hidden again. NULL is returned when the cursor was put in place by keyboard, because then there's really nothing to do.
* Guess: Make 'H' key work properly with "Allow duplicates" offBen Harris2022-12-23
| | | | | | | | Before it would not only generate an invalid guess, but also override the usual rules to allow you to submit it. Now guesses are only provided if they're valid, and I've adjusted the maximum-colour finder so that the code can actually find the correct guess. This should have no effect on the behaviour with "Allow duplicates" turned on.
* Solo: Set max difficulty for small jigsaw puzzlesMichael Quevillon2022-12-17
| | | | | (cherry picked from Android port, commit 5c9a7b64a06d07f97a41622c4b91d81f3419a51b)
* Prevent starting in a solved state in Fifteen & FloodChris Boyle2022-12-16
| | | | | (cherry picked from Android port, commit cb38abdc71780bd9b393b90514396c338306fa69)
* Remove _() introduced from Android port.Jacob Nevins2022-12-16
| | | | | Introduced in cbf2ede64a. It's used there for marking up text for i18n in a gettext stylee, but is not available here.
* lightup: Ban 2x2 with either 4-way typeChris Boyle2022-12-16
| | | | | | | | (2x2 with four-way symmetry must be either all-black (trivial) or all-white (ambiguous). --bjh21) (cherry picked from Android port, commit 27ae898e118b0a31a98d393bf56aa138845123e6)
* guess: Remove an obsolete workaroundBen Harris2022-12-16
| | | | dup_params() has taken a const argument for some time.
* magnetssolver: Add a missing newline to a messageBen Harris2022-12-15
|
* magnets: Area constraints; fix message.Chris Boyle2022-12-15
| | | | | | | | | | | (The restriction on 2x2 puzzles is because the board layer-out doesn't use neutral pieces on such small boards, and the only soluble 2x2 boards have neutral pieces. I haven't investigated the Tricky size limit, but it seems entirely reasonable that all the smaller boards are too easy. --bjh21) (cherry picked from Android port, commit 133794977a13767e0c1596be6a5b26f2cf2d1fd1)
* Tweak Filling greys to better distinguish selected and completedChris Boyle2022-12-15
| | | | | | | | If you accidentally selected a cell that was part of a completed area, it was hard to notice that you'd done so. (cherry picked from Android port, commit ca08cd832952cefd9a3b545f13785d7054a3e1f6)
* Update developer docs for mkhighlight changesBen Harris2022-12-15
| | | | | Specifically for passing -1 as a colour number, and for proper handling of dark backgrounds.
* Rewrite mkhighlight to handle a wider range of coloursBen Harris2022-12-14
| | | | | | | | | | | | | | Before, it worked by scaling all the colour components, which worked reasonably for colours in the vicinity of white, but failed badly on a black background. Now it generates the highlight and lowlight colours by mixing the background colour with white and black respectively. Where there isn't enough headroom, it adjusts the background by mixing in a negative amount of white or black, which makes sense geometrically if not in paint. There is still a problem that green and yellow colours don't end up with bright enough highlights. I think this is because the code doesn't understand that green is brighter than red or blue.
* Don't request a highlight colour in games that don't need oneBen Harris2022-12-14
| | | | | | | | This means that Range, Singles, and Tracks can now use the default background colour even if it's close to white. In the case of Singles I've left a dummy entry in the colour list so as not to renumber the rest and break everyone's environment variables. If Singles ever needs a new colour it can re-use that slot.
* Add an assertion that all colours are within rangeBen Harris2022-12-14
| | | | Because I know I'm going to mess this up at some point.
* mkhighlight: Don't darken the base colour if we don't need a highlightBen Harris2022-12-12
| | | | | | | | | | | The "mkhighlight" functions can now take -1 as the requested highlight or lowlight colour as an indication that no such colour should be returned. If the caller doesn't want a highlight colour, there's not much point in darkening the base colour to make it distinct from the highlight, so don't do that. This means that the background colours in Palisade and Untangle are no longer unnecessarily darkened.
* Pearl: make PEARL_GUI_LOOPY affect printed output.Simon Tatham2022-12-11
| | | | | | This display style is perfectly playable on paper (proof: it works for Loopy), so there's no reason not to support both modes in both output routines.
* js: When opening a dialogue box, try to focus itBen Harris2022-12-10
| | | | This will make using menus from the keyboard more convenient.
* js: Don't treat SoftRight as CURSOR_SELECT2Ben Harris2022-12-10
| | | | | | I was hoping that I could treat SoftLeft and SoftRight the same in C and arrange to filter one of them out in JavaScript, but that turned out to be impractical.
* js: Add a mode where the puzzle tries to fill the viewportBen Harris2022-12-10
| | | | | | | | | | | | | | | | This is activated by putting the puzzle in an element with id "puzzlecanvascontain". In that case, the puzzle's default size is as close to filling that element as is achievable. Unlike in the normal mode, this sets the CSS size of the canvas directly. Because it might take a little while for the page to settle down after loading, and because the size of the viewport might change, this listens for "resize" and "load" events, and only bothers changing anything when the page is fully loaded. Waiting for the document to be complete might be a problem if we had images and so forth that we could plausibly be waiting for, but we don't.
* js: Add a new function whereby C can ask JS for a preferred board sizeBen Harris2022-12-10
| | | | Currently JS has no opinion.
* js: Set the default colour from the CSS background of the canvasBen Harris2022-12-10
| | | | | | | This allows the HTML/CSS to decide that it would like a different background colour without the need to recompile. The default if the CSS specifies no colour (and hence the canvas is transparent) is the same grey as before.
* js: Allow CSS to set the font used by the puzzleBen Harris2022-12-10
| | | | | | | | | | | | | | This means that the calculated font properties of the HTML canvas now control what font is used. The size is overridden, and for monospaced text so is the family. I'd like to be able to also specify the monospaced font, maybe using a CSS variable, but that looks like being quite a lot of extra complexity. My experience when testing this was that constructing a valid "font" string for a canvas context is prone to breakage, but broke in a way that left the font unchanged, so we always set a simple specification first before trying to construct one from CSS.
* New backend function: current_key_label()Ben Harris2022-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This provides a way for the front end to ask how a particular key should be labelled right now (specifically, for a given game_state and game_ui). This is useful on feature phones where it's conventional to put a small caption above each soft key indicating what it currently does. The function currently provides labels only for CURSOR_SELECT and CURSOR_SELECT2. This is because these are the only keys that need labelling on KaiOS. The concept of labelling keys also turns up in the request_keys() call, but there are quite a few differences. The labels returned by current_key_label() are dynamic and likely to vary with each move, while the labels provided by request_keys() are constant for a given game_params. Also, the keys returned by request_keys() don't generally include CURSOR_SELECT and CURSOR_SELECT2, because those aren't necessary on platforms with pointing devices. It might be possible to provide a unified API covering both of this, but I think it would be quite difficult to work with. Where a key is to be unlabelled, current_key_label() is expected to return an empty string. This leaves open the possibility of NULL indicating a fallback to button2label or the label specified by request_keys() in the future. It's tempting to try to implement current_key_label() by calling interpret_move() and parsing its output. This doesn't work for two reasons. One is that interpret_move() is entitled to modify the game_ui, and there isn't really a practical way to back those changes out. The other is that the information returned by interpret_move() isn't sufficient to generate a label. For instance, in many puzzles it generates moves that toggle the state of a square, but we want the label to reflect which state the square will be toggled to. The result is that I've generally ended up pulling bits of code from interpret_move() and execute_move() together to implement current_key_label(). Alongside the back-end function, there's a midend_current_key_label() that's a thin wrapper around the back-end function. It just adds an assertion about which key's being requested and a default null implementation so that back-ends can avoid defining the function if it will do nothing useful.
* tracks: Allow a smaller or non-existent border at small tile sizesBen Harris2022-12-08
| | | | | | | | | | | | | | | | The basic tile size in Tracks is required to be a multiple of 6, which means that for small tile sizes the steps are rather large. With the standard border widths, this means that the default 8-by-8 puzzle can be 246 pixels wide (tilesize == 24) or 184 pixels wide (tilesize == 18). This is particularly annoying if you happen to have a 240-pixel-wide screen. This commit allows the puzzle to reduce or remove the borders at small tile sizes, on the grounds that a slightly narrower border is acceptable if it avoids needing to use a smaller tile size. It encodes the border width in (tilesize % 6), and is thus enabled when the default border width is 5 or less. Above that size (which is a tilesize of 48), I assume the steps in tile size aren't big enough to be a serious problem.
* tracks: Make the keyboard cursor more visibleBen Harris2022-12-08
| | | | | | | | | | The former grey was almost indistinguishable from its background colours even on a good screen. I've separated the cursor colour from the grid colour and made it a lot darker. This gives a contrast ratio over 3.0 even against a darkened tile. The cursor is still hard to see against trackwork, so maybe something that isn't grey would be even better.
* galaxies: Use the same code for handling all dropped arrowsBen Harris2022-12-07
| | | | | | | The keyboard code was prone to adding null items to the undo history, and was also unreadable. Rather than fix it, I've replaced it with a jump to the mouse drop handling, lightly enhanced to reject drops on things that aren't tiles.
* guess: Much more efficient keyboard interfaceBen Harris2022-12-07
| | | | | | | | | | | | | | Now rather than mucking around with the cursor keys, you can just type a four-digit number and press Enter. Of course, if you still want to muck around with the cursor keys they work the same as before. Since Backspace was already assigned to clear the peg under the cursor, I haven't co-opted it for the obvious action of clearing the peg to the left of the cursor and moving the cursor left. The left arrow key is a reasonable alternative anyway. For consistency, 'L' now labels the pegs with numbers rather than letters, and is documented.
* guess: Move the cursor to the first peg position after a guessBen Harris2022-12-07
| | | | | | It's annoying having to move it to the left each time. I suppose I could enter the second guess in reverse order, but then I'd need to move the cursor all the way to the right to submit it, which is just as bad.
* guess: Correct documentation to not say Space places a pegBen Harris2022-12-07
| | | | It sets a hold now, as is mentioned in the next sentence.
* js: Explicitly set the height of the status barBen Harris2022-12-06
| | | | | Otherwise it varies depending on whether it has any text in it, which is distracting.
* Assert that the back-end has provided a background colourBen Harris2022-12-06
| | | | | If we're going to refer to a specific colour, it seems appropriate to insist that it exists.
* Devel docs: explain the specialness of colour 0Ben Harris2022-12-06
| | | | | It's used to fill the drawing area and also by some front-ends (at least GTK and JavaScript) to fill areas around the drawing area.
* Devel docs: Mention mid-end background clearingBen Harris2022-12-06
|
* guess: Fix keyboard access to hold functionBen Harris2022-12-05
| | | | | | This has been broken since 2015. It was accidentally using "IS_CURSOR_SELECT(button)" in place of "button == CURSOR_SELECT" and these are not the same thing.
* js: Put the puzzle background colour in a CSS variableBen Harris2022-12-05
| | | | | | | | | It's sometimes useful to be able to have an HTML element that visually forms an extension of the puzzle's border. By putting the puzzle's colour 0 (which we assume to be its background) into a CSS variable, such elements can do something like "background-color: var(--puzzle-background)" to get that effect even if the puzzle uses a non-default background colour.
generated by cgit v1.1 at 2026-04-26 21:01:54 +0000