a year since the refactor that inspired leaving this logging in.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3961 542714f4-19e9-0310-aa3c-eee0fc999fb1
(It may be the same thing under the hood, but our pal Occam would approve.)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3958 542714f4-19e9-0310-aa3c-eee0fc999fb1
the screen. In general the first frame is thrown off by the time it takes to
construct the window (which may be substantial) and the second might take a
while laying it out. After that though, we can smoothly slide things onto the
screen, and so we do.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3942 542714f4-19e9-0310-aa3c-eee0fc999fb1
otherwise, everything under it will inherit the "SKIP" mode,
which bypasses the render queues.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3940 542714f4-19e9-0310-aa3c-eee0fc999fb1
than it needs to be.
Broke streaming compatibility in order to be much more efficient over the wire.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3938 542714f4-19e9-0310-aa3c-eee0fc999fb1
our streaming system should work with multidimensional arrays: in fact it
kinda already did, if the element type of the outermost array was something
for which we already had a streamer. Thus, int[][] worked, Object[][] worked,
etc. One small method change and now arbitrary multidimensional arrays
will work.
Why bother? Consistency, and the way I'm working on doing even the int[][]
arrays in actionscript supports unlimited dimensions, so why not?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3921 542714f4-19e9-0310-aa3c-eee0fc999fb1
previously redone the InvocationService and DObject generation tools but not
the InvocationReceiver tool.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3913 542714f4-19e9-0310-aa3c-eee0fc999fb1
frames. JME's timer was using a running average: good for calculating
frame rates, bad for updates.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3906 542714f4-19e9-0310-aa3c-eee0fc999fb1
databases configured to use utf8 encoding for their strings.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3899 542714f4-19e9-0310-aa3c-eee0fc999fb1
- View all colorization mode shows all the colorizations of a selection colorization class for the image.
- Normal mode allows modification by sliders of the colorization parameters.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3886 542714f4-19e9-0310-aa3c-eee0fc999fb1
(inStudlyFormat), it's just the constant that we use to reference that field in
code that's upper case. So we need to convert those as well. And I moved that
code into a documented method.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3884 542714f4-19e9-0310-aa3c-eee0fc999fb1
its method documentation). And I was doing the wrong thing with event names
which were already unstudlied (but are also uppercase).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3883 542714f4-19e9-0310-aa3c-eee0fc999fb1
- The range model was not correctly handling the case that the viewport in which we were arranging furniture was bigger than the area that the room wanted to cover. This problem never occurred in 800x600 mode, but could occur at larger resolutions in smaller rooms (such as shacks).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3874 542714f4-19e9-0310-aa3c-eee0fc999fb1
after updateRenderState in the third constructor, so the quad's render
state didn't include the alpha state. I changed it so that
updateRenderState is called in setQuad.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3859 542714f4-19e9-0310-aa3c-eee0fc999fb1
Mike Thomas