the PresentsClient which can then use it to fill in things like access
control information for the user. We could use this to replace the
UserStash mechanism we use on Yohoho, but that works so I doubt I'll do
that. However, this is needed to do things the more elegant way on future
projects, like Game Gardens.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3374 542714f4-19e9-0310-aa3c-eee0fc999fb1
day values to incorrectly always display as 0. I'm surprised nobody
else noticed this, it's right there on the blockade panel.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3372 542714f4-19e9-0310-aa3c-eee0fc999fb1
that were using the old default (usually null) to use the new default.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3369 542714f4-19e9-0310-aa3c-eee0fc999fb1
as they still implement get() and however they do that internally
is bound to be more efficient than doing the same thing through an
Iterator.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3367 542714f4-19e9-0310-aa3c-eee0fc999fb1
I just can't bear to see a useless object created (an Iterator) and
potentially a great many objects iterated past in order to find the
chosen random object when the original List is usually RandomAccess.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3366 542714f4-19e9-0310-aa3c-eee0fc999fb1
messages if repeat requests come in or for some reason the client and
server ever differ in opinion as to which scene the player is in.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3363 542714f4-19e9-0310-aa3c-eee0fc999fb1
by the MediaPanel as sprites that interact in some standard way with the
mouse.
Modified existing ButtonSprite to work this new way, and it now implements
CommandSprite, ArmingSprite, and DisableableSprite. One method name changed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3362 542714f4-19e9-0310-aa3c-eee0fc999fb1
together in one JVM and both interoperate with the AWT thread in a manner
so harmonious as to bring a tear to the eye. This was surprisingly much
easier that I expected, thanks to my eminently sensible initial design,
I'm sure. ;)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3360 542714f4-19e9-0310-aa3c-eee0fc999fb1
single player games and indeed should because it's useful outside the
context of puzzles and their ilk.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3359 542714f4-19e9-0310-aa3c-eee0fc999fb1
Could be made faster with some sort of reverse string lookup table,
but it doesn't seem worth the overhead right now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3352 542714f4-19e9-0310-aa3c-eee0fc999fb1
there will be relatively few of those (at most one per client that is
experiencing lag) and while the client is experiencing lag we will be
trying to write their data once per pass through the sockets (which could
be hundreds of times a second) and we don't want each write attempt to
result in the creation of a temporary direct buffer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3345 542714f4-19e9-0310-aa3c-eee0fc999fb1
another instance of append() that needed to be changed to appendLoud().
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3343 542714f4-19e9-0310-aa3c-eee0fc999fb1
Queue.append() only does a notify() if the queue was previously empty.
So when the dobj thread was requesting two sounds one after another, it
only woke up one player thread, which played the first sound and then
came back 'round to play the next sound after it was done. The next sound
was usually expired by that time.
Use queue.appendLoud(), which always wakes up a waiter thread.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3342 542714f4-19e9-0310-aa3c-eee0fc999fb1
getting dropped because they're taking too long to play. Extended the
max delay to 1000ms, which will surely help more sounds play, but may
not be worth it. Hey, we've got a test server to test on...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3337 542714f4-19e9-0310-aa3c-eee0fc999fb1
flattens messages into a buffer and then passes that bucket to a
SocketChannel.write() method which is part of the NIO business. If said
buffer is a "direct" buffer, the write() method will in theory do
high-performance shit like DMA the data right to the network card. If it's
not a direct buffer, Sun apparently makes a temporary direct buffer,
copies the data into it and passes that on to the underlying socket send()
call. We weren't using direct buffers which means that we were copying
everything one more time than needed (not a huge deal) and that we were
allocating a direct buffer for every message (a much bigger deal). This
should take a serious load off of the I/O thread and fortunately we can
test it on Ice to make sure it doesn't do anything super crazy.
All this said, this whole business is going to change when I rearchitect
Presents to avoid the potential race conditions it suffers from now and we
won't be able to use a single direct buffer to write all of our outgoing
messages, but I believe we will be able to use a pool of direct buffers
with one used by every message in the queue waiting to be written
(hopefully that won't be too many at any given time) which we can keep
around to avoid the expense of allocating and freeing direct buffers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3336 542714f4-19e9-0310-aa3c-eee0fc999fb1
sufficiently incompatible with GNU make that I'd rather just have two
whole separate goddamned directories with their own Makefile than try
to get everyone to agree on how to do things.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3328 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne