おなまえ
Ｅメール　 表示 非表示
タイトル
メッセージ auto soft pre(図表、プログラム) ※折り返さずに改行を入れてね
> > NP2でやってみた結果です。 > > 他のエミュの結果は全て以下の数値でした。 > > 表示は全く同じなので、おかしくないということですね。（違う！） > > NP2と他のエミュで差が出る、というところは一つの突破口かも。 > 少なくともNP2以外のエミュは仕様どおりではないということで、バグ報告は可能 > だと思います。おそらく、四捨五入するときの桁数を誤っていると想定されます。 > 仕様上は、有効桁７桁、出力のときは７桁目が四捨五入されて６桁で表示、という > ことになっているのですから。 > なので、以後は、NP2と実機の差異をどうするか。 > どうも、本来は７桁以上は格納してはいけないものを７桁以上格納している、その上 > ７桁以上で比較してはいけないものを７桁以上で比較している、というように見える > わけですよ。 > print usingを使う以外に、何かいい方法はあるかなぁ。 > > > 実際、この程度の小数の誤差がどの程度影響するかはわかりませんがね。 > でも、もしかしたら、昔からゲームなんかでも使われている可能性はあるわけで。 > konnoさんは、例えばバルーンパンチなんてゲームを覚えておられませんかね。 > シーソーに乗った人が交互にジャンプして上のほうで動いている風船を割っていく、 > というゲームです。 > このゲームで飛んでいる人間は、まるで重力で引かれるような感じで頂点に向かって > 減速して、また落下するときは加速するわけです。このゲームに限らず、まるで重力 > に引かれたような動きをする、だとか、慣性が働いているようになかなか加速しない > 上に速度が乗ったらすぐには止まれない、といった動きをするようなゲームでは、 > もしもそれなりに理論的なアルゴリズムを使うならば、物体の位置決定に二次関数を > 使う必要があるわけです。実際に使っているアルゴリズムがどこまで理論的に正しい > ものになっているかはわかりませんけどね。 > そして、二次関数を解くためにはSQR関数が必要。 > あるいは、ゲームによっては三角関数を使っているものもあるかもしれない。 > そして、画面のＸとＹの座標は当然整数。 > ときどき、当たり判定がバグっているゲームというのが話題になることがありますが、 > あれっていうのはもしかしたら、小数と整数の比較の際の誤差の問題かも。そして、 > 実機だと正常に動いていたのにエミュだとおかしい、というゲームなどがあった場合、 > それこそこのような小数の誤差の可能性は高いかも。 > もちろん、倍精度を使えば誤差は少なくなりますが、リアルタイムの計算の場合、 > 倍精度だとやっぱり重くなるので、たいていは単精度を使うでしょうし。 > >
参照先
暗証キー (英数字で8文字以内)
プレビュー