By default, it still does the same thing, but now you
can pass in a fancier packer.
Provided a SLIGHTLY fancier one that's still pretty dumb and
wasteful, but allows row wrapping instead of gluing everything
together into one super wide image; I've got some that otherwise
wind up SO insanely wide that it causes problems decoding them.
Introduced a Writer class to hold all the options to the createBundle method and help clarify
things. This also ended up being a convenient place to put the previous member variables since
they affect the process in pretty much the same way.
Got rid of DirectoryTileSetBundler. This had a mutated copy of a method from TileSetBundler,
that appeared to be missing some bug fixes. Anyway, it shouldn't be needed anymore, callers
can use a BundleWriter that is a directory.
Added an option for outputting tileset bundle metadata as json. This includes some
utility classes and the net.sf.json-lib dependency. This follows the same pattern
as some other tools only jars so should end up being ignored by production
applications.
Colorizations are not cached, and the root color values are recomputed
every time. We can share those.
Also added an accessor to read the already computed HSV values out
of a Colorization. I suppose I could just make it a public field
or return the array directly. The rootColor variable is already public.
DFU. But now the array will be shared by every instance from the same
classRecord, so it seems more important to make sure nothing goes wrong.
Noted one SWC that comes from our Google Code Maven repo which is going to have
to move somewhere else because the upstream maintainers abandoned the project
in 2011 and were never going to ship their stuff to Maven Central anyway. Sigh.
I have no idea if this is right, but otherwise I seem to be blocked on building
because of a missing SWC. Rage! Why am I blocked from making a jar file
because of some stupid flash shit that nobody will ever care about again?
David Hoover