ど?も、Salvoxです。

(相変わらず話が終わってるものに、蛇足を書き込んでしまいたくなる・・・)。

引用：

で、原因については野中さんに言われてしまったので、
僕は現場での経験から。

このフォーラムにも書いてあったと思うのですが、
Flashの内部演算は8bitでおこなわれてるらしい・・・。
だもんで、this._x += 1; とか、特に多いのは、this._alpha += 5;とかした時に、_alpha値が単純に10進数倍を取らず、
10.989864126...みたく小数点を含んで増減していくことがあると思います。理由は野中さんが言われた丸め誤差の原因と同じです。

実は、これが厄介もんで、たとえば、
_alpha値を、100でとめたつもりが、数値上では99.2222とかになって微妙にアルファーが掛かったまんまで、デザイナーに『表現が違うんだけど…』(こまか??!!)とか言われちゃったり、
もっと厄介だったのが、座標軸もので、最近ではそうは判定してないのですが、まだ僕が駆け出しだったころ、if(this._x == 100)
みたいに、ジャストで判定していたり、if(this._x < 100)とかで
判定していると、永遠に100にならない場合がおきたり、1pxにも拘るデザイナーに、『ズレてるんだけど…』(細かいんだよ!!)とか言われちゃったりして、大変な思いをしたことがあります。

で、そんなこんで、導いた対策(っというか常識?)
なるべく浮動小数点演算は避ける。と、直接、値をぶち込む時は
なるべく16進数表記(0x64)とかで値をいれると、かなり都合が(期待が)いい結果を得られます。

アルファーを変える時、座標を変える時は、元となる_x座標や各種値を事前にint()で、整数に変換してから演算したり、sin() や cons()を使う上でも、最終的に必要な値は整数で十分ですから、切り落としてから返して、次の処理の為に、場に散らばる浮動小数点を徹底的に排除しています。その方が演算も早いし、何よりバグになりにくい!!。

kumanekoさんがどういった内容を処理しているのか、分からないので的確なアルゴリズムが紹介できませんが、参考になるものとして、DDA(Digital Differential Analyzer)などがあります。
結構、簡単なアルゴリズムなので、ソースみれば即実装できると思います(一応、高速なアルゴリズムとされています)。

↑余談ですが、僕が現在使ってるモーション・ライブラリー(AS 1.0用)を近じか公開したいなぁ?なんて考えてたりします。
アルゴリズムはDDAを基本にしていますが、製作現場での実装に絶える仕様にする為、一年かけて改良し(これのどこがDDAやね?ん！)って言わんばかり、高速(自称)! になってます(自負(笑))。

ここの『ダウンロード』って、僕でも登録できるんですかね？？

----------------
(C)SalvoxStudioStation