| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To do this, I've completely replaced the API between mid-end and front
end, so any downstream front end maintainers will have to do some
rewriting of their own (sorry). I've done the necessary work in all
five of the front ends I keep in-tree here - Windows, GTK, OS X,
Javascript/Emscripten, and Java/NestedVM - and I've done it in various
different styles (as each front end found most convenient), so that
should provide a variety of sample code to show downstreams how, if
they should need it.
I've left in the old puzzle back-end API function to return a flat
list of presets, so for the moment, all the puzzle backends are
unchanged apart from an extra null pointer appearing in their
top-level game structure. In a future commit I'll actually use the new
feature in a puzzle; perhaps in the further future it might make sense
to migrate all the puzzles to the new API and stop providing back ends
with two alternative ways of doing things, but this seemed like enough
upheaval for one day.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
width and height by assuming mirror symmetry within the containing
applet area. Instead, use the proper width and height as given back
by the C sizing function.
(In particular, this fixes a bug where the non-blanked puzzle area
appeared too tall by the height of the menu bar, probably as a
result of confusing PuzzleApplet.getHeight() with
PuzzlePanel.getHeight(). But the mirroring approach was conceptually
wrong anyway.)
[originally from svn r9022]
|
| |
|
|
|
|
|
|
|
|
| |
new function in the drawing API which permits the display of text
from outside basic ASCII. A fallback mechanism is provided so that
puzzles can give a list of strings they'd like to display in order
of preference and the system will return the best one it can manage;
puzzles are required to cope with ASCII-only front ends.
[originally from svn r8793]
|
| |
|
|
|
|
| |
draw dotted lines. No puzzle yet uses this, but one's about to.
[originally from svn r8453]
|
| |
|
|
|
|
|
|
|
| |
argv[1], which in turn feeds it into the midend as a game ID. This
can of course take any of the forms supported by the native C
puzzles: a pure game parameter string, a params:description specific
game ID, or a params#seed random game ID.
[originally from svn r8095]
|
|
|
NestedVM. Wow!
[originally from svn r8064]
|
