<feed xmlns='http://www.w3.org/2005/Atom'>
<title>puzzles/penrose.c, branch rockbox</title>
<subtitle>My sgt-puzzles tree</subtitle>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/'/>
<entry>
<title>Apply the rotation in Penrose grid descriptions by rotating in the</title>
<updated>2011-05-06T17:09:03+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2011-05-06T17:09:03+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=4a172274f2abde1c2ad23ba46b183e1d767fb902'/>
<id>4a172274f2abde1c2ad23ba46b183e1d767fb902</id>
<content type='text'>
4-vector representation, rather than mucking about with sines and
cosines after grid generation. _Should_ make no difference in the
generated grids (there's a theoretical risk of an unlucky rounding
error just about managing to push some point in or out of bounds, but
I think it's vanishingly small), but simplifies the coordinate-
flattening procedure, and in particular increases its chance of
getting vertical lines actually vertical.

(Prior to this change, the game ID
10x10t12:G2554,-31,108_a3b12h0a212a3d102b2a23a2e3b01b0a2c2a0c0 was
generating a not-quite-vertical edge at top left, in the Java port but
not on Linux; I suspect differences in sin and cos as the cause of the
discrepancy. With the rotation done like this, the points'
x-coordinates are now computed without reference to their
y-coordinates.)

[originally from svn r9168]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
4-vector representation, rather than mucking about with sines and
cosines after grid generation. _Should_ make no difference in the
generated grids (there's a theoretical risk of an unlucky rounding
error just about managing to push some point in or out of bounds, but
I think it's vanishingly small), but simplifies the coordinate-
flattening procedure, and in particular increases its chance of
getting vertical lines actually vertical.

(Prior to this change, the game ID
10x10t12:G2554,-31,108_a3b12h0a212a3d102b2a23a2e3b01b0a2c2a0c0 was
generating a not-quite-vertical edge at top left, in the Java port but
not on Linux; I suspect differences in sin and cos as the cause of the
discrepancy. With the rotation done like this, the points'
x-coordinates are now computed without reference to their
y-coordinates.)

[originally from svn r9168]
</pre>
</div>
</content>
</entry>
<entry>
<title>Portability fixes, mostly from James for Palm purposes. Mostly</title>
<updated>2011-05-04T18:41:21+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2011-05-04T18:41:21+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=89bfecaa5aa39469a3e368d44f517aff5c904354'/>
<id>89bfecaa5aa39469a3e368d44f517aff5c904354</id>
<content type='text'>
additions of missing 'static' and explicit 'void' in parameter lists,
plus one or two other things like explicitly casting chars in variadic
argument lists to int and using DBL_MAX if HUGE_VAL isn't available.

[originally from svn r9166]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
additions of missing 'static' and explicit 'void' in parameter lists,
plus one or two other things like explicitly casting chars in variadic
argument lists to int and using DBL_MAX if HUGE_VAL isn't available.

[originally from svn r9166]
</pre>
</div>
</content>
</entry>
<entry>
<title>From James Harvey (via a period of collaborative polishing), a patch</title>
<updated>2011-04-24T09:10:52+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2011-04-24T09:10:52+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=62c20496bf106b1034f4be95bdb7723c3ec78d00'/>
<id>62c20496bf106b1034f4be95bdb7723c3ec78d00</id>
<content type='text'>
to add two kinds of Penrose tiling to the grid types supported by
Loopy.

This has involved a certain amount of infrastructure work, because of
course the whole point of Penrose tilings is that they don't have to
be the same every time: so now grid.c has grown the capacity to
describe its grids as strings, and reconstitute them from those string
descriptions. Hence a Penrose Loopy game description consists of a
string identifying a particular piece of Penrose tiling, followed by
the normal Loopy clue encoding.

All the existing grid types decline to provide a grid description
string, so their Loopy game descriptions have not changed encoding.

[originally from svn r9159]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
to add two kinds of Penrose tiling to the grid types supported by
Loopy.

This has involved a certain amount of infrastructure work, because of
course the whole point of Penrose tilings is that they don't have to
be the same every time: so now grid.c has grown the capacity to
describe its grids as strings, and reconstitute them from those string
descriptions. Hence a Penrose Loopy game description consists of a
string identifying a particular piece of Penrose tiling, followed by
the normal Loopy clue encoding.

All the existing grid types decline to provide a grid description
string, so their Loopy game descriptions have not changed encoding.

[originally from svn r9159]
</pre>
</div>
</content>
</entry>
</feed>
