131 |
(meaning that when using OrthoCoorder, you would often create coordsys |
(meaning that when using OrthoCoorder, you would often create coordsys |
132 |
with width = height = 1, because you do not want scaling). |
with width = height = 1, because you do not want scaling). |
133 |
This isn't very elegant, especially because vobs aren't truly |
This isn't very elegant, especially because vobs aren't truly |
134 |
(graphically) scaled by changing their coordsys' width and height... Hm |
(graphically) scaled by changing their coordsys' width and height... Hm<br> |
135 |
</p> |
<br> |
136 |
|
(Tjl:) Of course, the API needs changing in that case. Something like<br> |
137 |
|
</p><tt>/* Get a coordinate system which is translated dx, dy from the given coordinate</tt><br> |
138 |
|
<tt> * system.</tt><br> |
139 |
|
<tt> */</tt><tt><br> |
140 |
|
int translate(int transBy, int clipBy, Object key, float dx, float dy);</tt><br> |
141 |
|
<br> |
142 |
|
And so on. Affine coordinate systems would also have <tt>rotate</tt>, and |
143 |
|
with that we would actually get rid of the current problem with affine coordsys |
144 |
|
interpolation as well, where interpolation across a rotation shrinks (since |
145 |
|
the coefficients go linearly), getting us closer to the semantics. <br> |
146 |
|
<br> |
147 |
|
This takes us closer to a scene graph... maybe that's a good thing. It may |
148 |
|
be easier to explain to people that Vob coordsystems are nodes in a scenegraph |
149 |
|
that get identified with nodes in another scene graph.<br> |
150 |
|
<blockquote><br> |
151 |
|
</blockquote> |
152 |
|
|
153 |
|
|
154 |
<p> |
<p> |
155 |
|
|
182 |
<br> |
<br> |
183 |
<br> |
<br> |
184 |
<br> |
<br> |
185 |
</body></html> |
<br> |
186 |
|
</body></html> |