became necesssary when *Codes were moved out of .client and into .data.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1247 542714f4-19e9-0310-aa3c-eee0fc999fb1
instead we say that we want to scroll by a certain amount in a certain
amount of time. This allows the animated panel (who knows about this
stuff) to figure out when to stop scrolling without overshooting by a
pixel or two.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1244 542714f4-19e9-0310-aa3c-eee0fc999fb1
as they are intended to represent codes shared between the client and the
server. Made correspondingly necessary changes throughout.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1240 542714f4-19e9-0310-aa3c-eee0fc999fb1
start processing on the server so that we don't want for the IN_PLAY
attribute change to be processed before calling gameDidStart() because we
don't want to do that when resetting the game (because someone could come
along and end the game in between gameWillStart() and gameDidStart() which
would be annoying and bad), so we need to be consistent and run straight
through both when starting the game for the first time and when resetting
it.
This means that game managers that really need to wait until their events
are processed and do some game start processing at that point will have to
listen for the IN_PLAY transition themselves *and* they'll have to be
aware that someone could have come along and ended the game in between the
call to gameDidStart() and the dispatch of the IN_PLAY event. Sketchy, but
unavoidable.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1235 542714f4-19e9-0310-aa3c-eee0fc999fb1
message events) to a transaction already started on a particular object.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1233 542714f4-19e9-0310-aa3c-eee0fc999fb1
ends in Set as a DSet. This is not optimal, but writing a full blown
parser so that we can analyze the inheritance hierarchy of the files we're
processing to determine for sure that something extends DSet would be at
least an order of magnitude greater pain in the ass than just doing simple
textual processing. We'll leave that up to future people.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1232 542714f4-19e9-0310-aa3c-eee0fc999fb1
Clearing a base tile sets it to a random tile from the default tileset.
setBaseTiles() now takes a tileset and fills the rectangular area with
random tiles from that set.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1227 542714f4-19e9-0310-aa3c-eee0fc999fb1
If fringing an entire scene, you must pass in a randomization seed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1226 542714f4-19e9-0310-aa3c-eee0fc999fb1
Quoth the java.awt.Polygon documentation:
The first and final pairs of (x, y) points are joined by a line
segment that closes the polygon.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1222 542714f4-19e9-0310-aa3c-eee0fc999fb1
since the autofringer can create any fringe now anyway.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1219 542714f4-19e9-0310-aa3c-eee0fc999fb1
fucking serialization crapping out when the class was recompiled and its
panties got into a bunch.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1216 542714f4-19e9-0310-aa3c-eee0fc999fb1
try decomposing the bits into contiguous regions and see if we
can't get fringe indexes for those regions.
This makes everything always fringes everywhere.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1211 542714f4-19e9-0310-aa3c-eee0fc999fb1
ImageUtil.composeMaskedImage() to create the masked fringe images.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1204 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne