- Reworked colorization repository such that we now have arbitrary named
"colorization classes" which can be used by various and sundry entities
to colorize themselves.
- Added support for individual object colorizations as well as "spots"
that go along with objects (will be used to automatically create portals
into buildings and automatically position users properly when at a
"station").
- Repackaged things in miso to more closely mimic what we do everywhere
else (no more miso.scene, now we have miso.data and miso.client).
- Fixed up miso scene XML representation so that objects can more easily
be expanded to have yet more stuff if we think of more stuff that they
might aught to have in the future. Structured the miso scene model so
that "uninteresting" objects (those that simply sit somewhere and don't
do anything) take up a lot less memory than "interesting" objects (those
that have action strings, "spots", colorizations and the works). I may
want to roll colorizations into the "uninteresting" realm, but that
remains to be seen.
- Made it possible for object tilesets to specify default render
priorities for objects in that tileset. This will hopefully allow us to
get by without any "custom" render priorities that are specified on
scene objects, instead relying on the default priorities to resolve
common conflicts.
There are surely other cleanups in there, but I think that was the major
thrust of it.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2228 542714f4-19e9-0310-aa3c-eee0fc999fb1
model as we'll be having scene names in the runtime system.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@757 542714f4-19e9-0310-aa3c-eee0fc999fb1
the way I was doing inheritance between the display and editable scene
implementations was not copacetic. The new method (which is for every
editable scene impl to delegate to a display scene impl so that regardless
of how far along you are on the inheritance chain, there are only ever two
actual objects, the display impl and the editable impl) is somewhat
cleaner, but makes it clear that no method can work as nicely as it would
were we to have mutliple inheritance.
The basic problem is that the editable versions of the scenes have to be
able to manipulate the instance variables in the display versions of the
scenes because they have to keep them up to date so that they are
displaying the right thing. As the editable versions are in different
packages, they don't have access to the display instance variables, so the
display versions simply have to make available enough "editable"
functionality to allow the editable versions to get their job done. It's
more coupling that I'd like, but at least it's only between the display
and editable versions across the inheritance hierarchy rather than down
the hierarchy.
Blah.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@745 542714f4-19e9-0310-aa3c-eee0fc999fb1
the new new style (or was that the new new new style).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@739 542714f4-19e9-0310-aa3c-eee0fc999fb1
Augmented standard scene and spot scene models with versions that provide
access to data only needed by the editor and loader. Filtered that whole
paradigm down through the locations and portals and all that.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@737 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne