おちゃめくらぶ掲示板 - 1659321896

2282：御茶目菜子：2014/11/25(火) 23:59:06: レスにょ
チラシ裏次郎さんへ
＞「賞品(の提供)をお願いします」と書いた部分は、
＞どう解釈して読み取られたのかわずかに気になったり(笑)

「同業他社な賞」という名称から同業他社に与える賞かと思っただけにょ。（笑）

＞X軸は、フタを閉じるような方向の向きで、
＞　コロコロカービィの跳ねるような操作
＞Y軸は、自動車運転のハンドルのような操作、
＞Z軸は、隣の人に画面を見せる時のような操作、

X軸は私も同意だけどY軸、Z軸は逆のようなイメージがあるにょ。

＞・・・自分で実際に動かしながら数字見た方が早いなｗ
＞文字だけの限界ですねえ、アニメーションgifでもあれば一発で伝わる

アニメーションGIFで説明するのが一番分かりやすいにょ。
ジャイロセンサーの情報とモーションセンサーの情報は同じX、Y、Zであっても根本的に
異なることに注意が必要にょ。

＞目と3DSの距離を変えるが、その動きを感知して
＞ハカセの顔の表示上の大きさが変わり、
＞肉眼で見たハカセの大きさは変わらない
＞みたいな時は、どのセンサーの値を使えばいいんかな

距離情報を取得する方法はないし、同じ角度を維持したまま等速移動をした場合にはどちらの
センサーでも感知しないにょ。
強いて挙げるならば最初の位置を粗方決め手おいて動かす瞬間の加速度から速度を求めて
その経過時間で移動距離を求める程度のことしかできないにょ。
最初が60cmで30cm移動したのならばハカセを2倍に拡大すれば同じ大きさに見えるにょ。

＞サブルーチンと関数での速度の差や
＞浮動小数点変数と整数変数の速度差の調査ヨロシクです（丸投げ）

とりあえず、計測してみたにょ。
まずは関数とサブルーチンの速度の違いを見てみるにょ。

DEF ADD(A,B)
C=A+B
RETURN C
END
関数　322フレーム

@ADD
C=A+B
RETURN
サブルーチン　67フレーム

このフレーム数は100万回実行時のものでループに使用したFOR～NEXTにかかった時間を
差し引いた純粋な処理時間にょ。
これを見ると5倍くらいの速度差がありそうだけど実際はそうではないにょ。
というのも関数を実行時にはGOSUBとは比べ物にならないくらいのオーバーヘッドがある
ためにょ。
引数が2つだと250フレームがオーバーヘッドであり、要するに250フレーム分だけ遅くなる
ということにょ。
実際に遅くなるのはその250フレームに加えて1割程度にょ。
単なる加算というシンプルな関数だとその250フレームが莫大な差になるためここまで大きな
速度差になっているわけにょ。

整数型と実数型（倍精度浮動小数点）の比較をしてみると普通に使った場合には予想に反して
その差はほとんどないにょ。

A=A+1　　21フレーム　倍精度浮動小数点
A%=A%+1　22フレーム　32bit整数
A=A+1　　16フレーム　OPTION DEFINTによる整数

上記のようにこの例では逆に1フレーム整数型の方が遅くなっているにょ。
整数型が本領を発揮するのがOPTION DEFINTを使った時でこの場合は実数型と比べて概ね
3割程度の高速化が可能になっているにょ。

簡易バルさんへ
＞プチコン3号の自作関数の仕様はとてもわかりづらいと思います。

本来は非常に分かりやすい仕様のはずだけど現状ではバグのためか不可解な挙動をすることが
非常に多いにょ。
私も試してみたけどDEFによる関数定義をした場合にその関数内で使われているのと同名の
グローバル変数がDEFより前に存在すると本来であればローカル変数になるはずの関数内の
変数がグローバル変数になってしまうにょ。
そのためVARで明示的な定義を行うと二重定義エラーが発生してしまっていると推測するにょ。
これがDEF～ENDより後に関数内で使用している変数と同名のグローバル変数があった場合には
関数内ではローカル変数となりちゃんと区別して扱われるにょ。

＞しかし、なぜこうなるのか・・・僕にはわかりません。（プチコンが初プログラミングです）

たぶんバグだと思うにょ。
現状ではこういったバグ、もしくはバグのような挙動をするものが多々あり、正直言って
初めてプログラミングする人にプチコン3号をオススメしずらい状況にあるにょ。
個人的にはmkIIをオススメしたいけどプチコン3号はmkIIから仕様が変わった部分が多くある
ためmkIIになれると逆に3号で勘違いをしてしまう場合もあるということからプチコン3号を
やりたい人にはver3.1が出てからにするのが最もオススメにょ。

天郷思音さんへ
＞mkIIから3号にデータを移すっていうのは誰もやらないの？

mkIIで作ったゲームの移植ならばPC→3号ではなくmkII→3号の方が便利とはいえプチコン3号に
転送するならば事実上音声経由にするしかなくmkIIでは厳しいためではないかと思われるにょ。
PC→3号の方が転送速度が稼げるためmkII→PC→3号とワンクッション増えても結果的には短い
時間で転送が可能になるにょ。

＞うわあmkIIのハフマン符号化もどきを3号に移植したら元プログラムにミス発見w
＞たまに起こってた不調の原因はこれかw
＞ちなみに動作確認用のテキストにもスペルミスが。"This"が"Tihs"になってた。

原因不明のバグがある場合には初歩的なミスであることが非常に多いにょ。
私もプラスとマイナスを間違えてしまい「間違えがないのに動かない」と悩むこともたまに
あるにょ（笑）

＞3号にDEC INCという加減算専用命令ができましたが、速度面では意味はあるんでしょうか？

私も試してみたけど速度面では全く意味がないにょ。
A=A+1とINC Aは仮想マシン語コードに変換した際に同じコードになっているのではないかと
思わせるレベルにょ。
INCはPLAYER_ZANKIのように長い変数名の時に効果を発揮するにょ。

PLAYER_ZANKI=PLAYER_ZANKI+1
INC PLAYER_ZANKI

どちらの方が短くて間違えにくいかは一目瞭然だと思うにょ。

ちびのりさんへ
＞わかりやすい解説ページありがとうございます。これからもお願いしますッ

ぜひポケコンでのプログラミングを頑張ってにょ！