"keepRawPngs" is a bit confusing since we tend to refer to the
FastImageIO format as "raw"
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@933 ed5b42cb-e716-0410-a449-f6a68f950b19
Still to do:
- Handle tile priorities in ISO sorting.
- Handle recoloring tiles (this may result in annoyingly significant changes to Tile/TileSet API)
- Dynamically loading sections rather than loading all the tiles of a scene.
- Better handling of the state where the scene's not yet loaded.
- Portals.
- Dynamic sizing of the MisoScenePanel
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@932 ed5b42cb-e716-0410-a449-f6a68f950b19
If it's public, we try to shadow it in a subclass & wind up
still getting THIS one.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@929 ed5b42cb-e716-0410-a449-f6a68f950b19
It's really handy when you've got objects that hide others to be able to
turn off the objects but still get footprints.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@919 ed5b42cb-e716-0410-a449-f6a68f950b19
the Node class public so that I can see where I came from in my Stepper.
The thread non-safety only affects callers of getConsidered(), btw.
If I wasn't pinched for time right now I'd modernize this whole thing
and remove the sucky.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@915 ed5b42cb-e716-0410-a449-f6a68f950b19
Whatever: this class needs a kick to the head.
Maybe I should make a new one that isn't singleton and thread-unsafe
like this one.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@914 ed5b42cb-e716-0410-a449-f6a68f950b19
the tests on every "dist" build, we'll just stick with the current behavior of
only compiling the tests (to make sure they don't rot). In a better world
ooo-libs would have a testall target which runs the tests on all the projects
it builds, so that we actually got the benefit of the few unit tests we have.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@909 ed5b42cb-e716-0410-a449-f6a68f950b19
If we're freaked out enough that we're carping & ignoring it, I want to
be able to actually figure out what's broken.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@906 ed5b42cb-e716-0410-a449-f6a68f950b19
exact same API. So if you ship with GC instead of Guava, nothing will break.
Eventually we'll want to ship with Guava instead of GC so that we can use
Guava-specific methods, but projects can make that switch at their leisure.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@905 ed5b42cb-e716-0410-a449-f6a68f950b19
toArray(ArrayList<Float> list) which erase to the same argument types. They
differ in return types which means that the JVM recognizes them as different,
so when the compiler resolved that it needed to call
"toArray(Ljava/util/ArrayList;)[F", it was not a problem that
"toArray(Ljava/util/ArrayList;)[I" also existed.
javac 1.7 is a bit stricter about this sort of thing and issues a concerned
warning message. Since the ArrayList<Integer> version is not used, I'm nixing
it to avoid confusion.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@903 ed5b42cb-e716-0410-a449-f6a68f950b19
The Scene Resolver thread and the dobj/AWT thread both talk to the _blocks map. And if the resolver tried to get while someone else was doing a put(), that put could decide to resize/rearrange the map. Which could result in the resolver not finding its block. Which resulted in annoying missing tile blocks. So - ConcurrentHashMap it up.
Woo!
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@894 ed5b42cb-e716-0410-a449-f6a68f950b19
I've been doing a whole bunch of AnimationSequences and 99% of the time
it's been one of those two stupid simple cases, so make them stupid
simple to do & stop cluttering up my code with extra args to linewrap.
git-svn-id: svn+ssh://src.earth.threerings.net/nenya/trunk@888 ed5b42cb-e716-0410-a449-f6a68f950b19
Mike Thomas