thing before committing instead of just going "oh yeah, I've been having this stuff
sitting around uncommitted for a while waiting on it to be blessed" and missing
out on things that'd changed in the meantime.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@665 ed5b42cb-e716-0410-a449-f6a68f950b19
play a particular key.
Set the gain on streams before returning them in addition to during each update.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@644 ed5b42cb-e716-0410-a449-f6a68f950b19
visible to things that don't want or care about OpenAL. Also, the openal
package is conditionally compiled, so this would have broken a Narya build that
didn't use the OpenAL libraries.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@624 ed5b42cb-e716-0410-a449-f6a68f950b19
AbstractSoundManager and implement the actual sound playing with Java sound in
SoundManager and with OpenAL in OpenALSoundManager. I left the SoundManager
name alone so nothing using it will need to change, but if nothing besides
yohoho is using it, I can refactor it to a more sane naming scheme.
Rip out all the music and alternative format stuff since it didn't work anyway.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@622 ed5b42cb-e716-0410-a449-f6a68f950b19
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
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
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
Dave Hoover