forum > Followup on the "turning crank"
-
Mike Robinson Mar 16 at 18:00
As I annoyingly expected, the resolution of the "turning crank or knob" issue that I spoke of previously turned out to be a simple matter.
The idea was that the object rotates around a center knob, has a handle on the end, and has a middle-control that can slide along its length.
As originally built, the "center knob" was a sprite, with a bitmap for the center-image attached to it and with additional sprites, each one with their own attached bitmaps, also attached to it:
knob_sprite --> knob_bitmap --> middle_control (middle_bitmap) --> end_handle (end_handle_bitmap)(where "(parentheses)" indicate children of the added respective sprites.
---
The correct topology turned out to be define a single sprite to represent the control itself, then to add to that sprite three sprites (each with their associated bitmap children): one for the knob, one for the middle control, one for the handle. Give each one of these a negative (X,Y) offset equal to one-half its width and one-half its height, respectively. So, if the "center knob" is 50x50 pixels, its local coordinate will be (-25,-25) and so on.
The original mistake was to attach the other objects to an offshoot of "the center knob" and to use that sprite to represent "the thing itself."
When the apparatus is built in this way and with the local (X,Y) coordinates arranged to suit, the apparent "center of rotation," of the center-knob and therefore seemingly of the entire contrivance, can appear to be anywhere, not just the center.
It also proved to be necessary to add code to the "mouse up" routines that would ensure that the Y-coordinate, particularly of the middle-control that can slide, is always "negative one-half the height of the control's bitmap," so that nothing would ever cause the control to move away from the bar on which it slides. Similar logic was used also in one case when the entire contraption is supposed to be "stretchy" ... able to be made longer or shorter while still maintaining its proportionate positioning of the center control.
-
Mike Robinson Mar 16 at 18:05
Postscript: If it is desirable for the "handle on the end" to appear to remain upright, i.e. not to be turning along with the crank (as is customarily the case for a real crank so that it doesn't rub your hand while turning), a local negative-rotation must be applied to the handle-sprite, opposite the rotation that is now being applied to the object itself. Turn the crank, say, clockwise, and the handle is silently turning itself counter-clockwise in an equal amount so as to remain "upright." Its local X,Y coordinates do not change.)
-
Mike Robinson Mar 16 at 18:11
Post-PostScript: :-D
One object needed to look like a student's protractor: a semicircular object. The best place for it to appear to "rotate from" is the bottom of its center. So the X-offset is one-half its width and the Y-offset is its full height. With this done, and with the "fourth sprite to contain them all" arrangement previously described, the desired effect is effortlessly achieved.
No monkey-business math, with matrices and so-forth, proved to be necessary in this case. (Of course, the negative-offsets are basically doing this "monkey-business math" for us.)
This appears to be how Adobe actually implemented the "registration point" feature which is exposed in their user-interface but not, AFAIK, to the ActionScript (hence Haxe) language: a child-sprite with a negative offset that doesn't move or rotate, then, rotate and move and otherwise manipulate the parent.
(Whew. I had to get all that documented, if only for the next time that I forget it. I'm done now.)
