5 Commits

Author SHA1 Message Date
9cfc61c5f7 In the Java front end, don't try to guess the puzzle rectangle's
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]
2010-11-06 18:14:41 +00:00
9fbb365684 Introduce, and implement as usefully as I can in all front ends, a
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]
2009-12-27 10:01:16 +00:00
407f29c46f Introduce some infrastructure to permit games' print functions to
draw dotted lines. No puzzle yet uses this, but one's about to.

[originally from svn r8453]
2009-02-22 12:05:38 +00:00
0c88256a22 Handle a <param name="game_id"> by passing it in to the C side as
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]
2008-06-26 19:09:07 +00:00
dd85394bf6 Michael Schierl's patch to compile the puzzles as Java applets using
NestedVM. Wow!

[originally from svn r8064]
2008-06-10 20:35:17 +00:00