heading = forwardDirection + rotationDegrees (was Re: How can we deal with Message rot?)
Hi Bert,
Thanks for your thought on this.
Bert Freudenberg bert at freudenbergs.de Wed Dec 27 14:14:12 UTC 2006 wrote:
On Dec 27, 2006, at 6:36 , Jerome Peace wrote:
more details of the heading etc. confusion can be found mantis
http://bugs.impara.de/view.php?id=5674
0005674: Why doesn't heading = forwardDirection + rotationDegrees for all morphs all the time?
As far as I know, rotation and animation (that is,
LOGO-style turtle
semantics) is only seriously used in Etoys.
I think it only seems this way.
First, I am making the assumption that by eToys you are refering to programming with tiles, Players etc.
The larger realm of eToys also consists of morphs and their behavior (particular behavior in response to halo handles). So what affects programming with tiles spills over into morph considerations.
For most other UI users it's merely a gimmick, so you would not need to worry
about backwards
compatibility too much.
Ok. thanx.
Etoys uses a very small set of messages (manifest in the Player class). As long as you ensure
this small
protocol does not break, Etoys should be fine.
Now, Player is very careful to always figure out the
"right" morph to
apply rotations to, depending on whether it wants to
be "flexed" (in
a TransformMorph) or if it handles rotation itself
etc.
Etoys player would benifit greatly from knowing less about how a morph carries out its tilting responsibilities. That means establishing a consistent language and having all classes (and their programmers and maintainers) stick to it.
This is the task of an oft promised but long overdue refactoring of morphic stuff.
I haven't worked out the details but the notion I have is that it should be possible to say
"player assuredFlexibleCostume heading: aHeading "
and have the right thing happen.
And maybe later "player assuredSimplestCostume"
which would remove redundant renderers.
This is why you see inconsistent behavior in the individual morph
classes.
But it shouldn't be that way. The responsibilities can be clearly defined and every morph would benifit.
Many of the deep bugs I run into have the TransformationMorph decorator as their root. Lots of the gribble leaving problems come from a mismatch of assumptions between TfMorph ( which believes you can translate the origin into the 3rd quadrant) while every body else believes that truncate is the same as floor because all points are in the 1st quadrant. Clipping boxes get calculated wrong and are often of by one just when you need them not to be.
Results: screen gribbles abound.
- inEtoys they are not used directly, but through the
Player, and this is
why your equation does not hold for each individual
morph. I think
you would have to eliminate TransformMorph
completely, which might
complicate other Morphs - until now, that "ugly"
transformation stuff
was factored out.
As I look at the code I see constant attempts to worry about which morph is actually being talked to renderer or renderee. The code practically begs to be refactored. Its just a big job at the moment. I await enlightenment and inspiration. Meanwhile I am trying refactorings that lay the ground work for the simplification of the Tf mess.
Yours in service, --Jerome Peace
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com