convert whatever its internal format is into ARGB for our inspection. It's
arguably a smidge slower (though we eliminated the multiple method calls
per pixel to determine whether it is non-transparent), but will work with
any source and destination image format.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2220 542714f4-19e9-0310-aa3c-eee0fc999fb1
createImageMask() not to freak out if the source image is not RGBA, Java
automatically unpacks pixels appropriately for 8-bit colormapped images,
so there's no need to be so picky. In createTracedImage() we were
converting the image to a screen optimized image anyway and thus the
source image format had absolutely no bearing on what we did with the
image later.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2218 542714f4-19e9-0310-aa3c-eee0fc999fb1
- All images are loaded through the image manager
- Architected to allow the use of prepared or unprepared images (and
volatile images when the day comes that they support alpha)
- Tunable caches for images and tiles
- Resource manager caches unpacked resources on the filesystem
- Various and sundry other cleanups
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2116 542714f4-19e9-0310-aa3c-eee0fc999fb1
would sure be nice to have a variant that traces the supplied image rather
than always creating a new one, and more flexibility with respect to the
alpha gradient steps might be nice, but all of that sort of thing will
just have to come later.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1950 542714f4-19e9-0310-aa3c-eee0fc999fb1
configuration as another and one for computing a rectangle that bounds all
non-transparent pixels in an image.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1483 542714f4-19e9-0310-aa3c-eee0fc999fb1
in the same package. Also added support for applying a set of
recolorizations all at once so that previous recolorings aren't borked by
subsequent recolorings (plus it's more efficient).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1340 542714f4-19e9-0310-aa3c-eee0fc999fb1
longer provide access to their underlying image (they actually still do,
but not in the normal course of affairs). This will allow us to use
"trimmed" tiles which are trimmed to the smallest rectangle that contains
the non-transparent pixels in a tile image, which will shrink up our
components and other tiles a great deal.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1339 542714f4-19e9-0310-aa3c-eee0fc999fb1
indexed color and it converts colors that are close to a target color in
the HSV color space (with specifiable bounds on difference in hue,
saturation and value) to new colors (with specifiable offsets for hue,
saturation and value). Initial testing shows great promise for articles of
clothing and even reasonable results on skin tones.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1069 542714f4-19e9-0310-aa3c-eee0fc999fb1
TRANSLUCENT since that's what we prefer. Made ImageManager use ImageUtil
to create blank images.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@871 542714f4-19e9-0310-aa3c-eee0fc999fb1
with the destination screen device. Updated existing code that previously
created buffered images directly to reference ImageUtil.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@870 542714f4-19e9-0310-aa3c-eee0fc999fb1
can't load the ImageIO classes. This unfortunately means that we're back
to passing a Component instance to the ImageManager at construct time.
Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@749 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne