Since its dirty regions propagate out to the repaint manager, a big update
there would lead to dirty calls ping-ponging back and forth for a few cycles.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@600 ed5b42cb-e716-0410-a449-f6a68f950b19
current run through the sound when stop is called before actually stopping.
Add a runnable to the lock method that will be called on the spooler thread
when locking is complete.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@597 ed5b42cb-e716-0410-a449-f6a68f950b19
saver that is Eclipse's "Infer generic types" which leaves HashMap and
ArrayList as the declared type where I would normally prefer to change those to
Map and List and use Maps and Lists to instantiate them.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@593 ed5b42cb-e716-0410-a449-f6a68f950b19
skiptacularly and try going back to using line.drain since our sleep until we
figure the sound will be done method wasn't working so well with the larger
buffer. Hopefully drain has been fixed in the 4 years since it was commented
out.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@590 ed5b42cb-e716-0410-a449-f6a68f950b19
I had a bug that managed to essentially let me function thanks to a hybrid
of the two modes. Unfortunately, it means things are as jerky as I had
originally feared for stuff like swordfighting and sailing, but I just played
a bunch of those, and while it's certainly not great, it's not TOO terrible.
But I definitely wouldn't want to be in a SF tournament in this mode...
Also, rip out ancient subinterval keyboard business since the seas of comments
there were getting in my way and confusing my text editor all through this
work.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@589 ed5b42cb-e716-0410-a449-f6a68f950b19
on windows, so add a whole buttload of debugging I can turn on and cry while
sifting through.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@588 ed5b42cb-e716-0410-a449-f6a68f950b19
that generate wide versions of the latin characters, which has
the nasty side effect of sending keyTyped events instead of
keyPressed and keyReleased events.
This extends the KeyboardManager to be able to cope with such
situations, doing sane things in that case. Unfortunately, since
you only get one event for the character, we don't really know
when it went down and when it came up, so we fake it by turning
native keyboard repeat on and pretending the key was held down
for one repeat's worth of time. While extreme values on the
system's key repeat or the desired KeyTranslator's repeat rate
could give unfortunate behavior, with sane values like people
typically should be using, it should all work. Swordfighting
and sailing (the two big users of keyPressed & keyReleased events
in yohoho) seem to be completely playable for me when running like
this.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@580 ed5b42cb-e716-0410-a449-f6a68f950b19
unneeded imports.
I've got partially completed patches for narya & vilya, too, but nenya was the
only one that wound up in a decent state after a friday evening puttering at it,
killing time waiting on other things to finish.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@572 ed5b42cb-e716-0410-a449-f6a68f950b19
method and bloat up the code a bunch, let's just do the brief, inline thing we
were doing in the first place.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@567 ed5b42cb-e716-0410-a449-f6a68f950b19
render sprites and animations over the top of everything in the frame:
JComponents, MediaPanels anything we like. To support this, we have the
MediaOverlay tell the ActiveRepaintManager when it has dirtied an area of the
screen and it will mark that component as needing repainting. Peachy.
However, if a component decides on its own that it needs repainting, we need to
propagate that now dirty region up to the MediaOverlay so that it can repaint
anything that's above the just-repainted component on the same frame tick.
This also fixes a potential problem if a changed sprite dirties a component
which then repaints itself but the bounds of that component overlapped some
other sprite which was not going to be repainted on this tick.
There were also potential problems if components were put in the JLayeredPane
layers (which are "above" the normal components and MediaPanels but "below" the
MediaOverlay). They too should now properly dirty regions in the overlay.
It occurs to me though that if a MediaOverlay sprite is on top of a MediaPanel,
the MediaPanel will probably not properly propagate its dirty region to the
overlay because the MediaPanel is a frame participant, not a JComponent and its
repainting is handled by the FrameManager not the ActiveRepaintManager. I may
just use the sledgehammer approach and dirty in the media overlay the entire
bounds of a frame participant if it paints anything on a frame rather than try
to translated and propagate its underlying dirty regions up to the overlay.
Oh the twisty maze of passages we've created in trying to create an active
rendering system that works magically with Swing.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@566 ed5b42cb-e716-0410-a449-f6a68f950b19
Fringe tiles are added to a WeakHashMap used across the scene panel as they're
created and then held with hard references by the scene blocks they're in.
Whenever the last scene block referencing a fringe tile goes out of the
influential radius, the fringe can be collected from the cache. In fringe
heavy scenes this reduces the memory for fringe by a third.
* Remove the mask cache
The fringe cache reduced the number of times a mask needs to be generated, so
eliminate the mask cache in the hopes of reclaiming a little more memory.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@548 ed5b42cb-e716-0410-a449-f6a68f950b19
Charlie Groves