みき★さんへ 結構ストレートに書いたつもりですが控えめですか？（笑） でんぺんさんへ 3.2.0→3.2.1→3.3.0→3.3.1という感じで仕様の追加や変更のあとはバグフィックスを短い間隔で行うのがベターかもしれませんね。 れいさんへ 実数型が速くなったせいでA=A+1の部分をA%=A%+1と記述すると逆に遅くなるケースがあるということです。 もっとも普通に使う際にはそれが問題になることはありませんが。 ヨッシーさんへ ver.3.0.0では普通に乗算が除算より速かったので今後のバージョンアップで改善される可能性はありますが、配列が遅いのは最初からなのでプチコン3号の仕様で終わりそうな気がします。

みき★さんへ OPTION STRICTは記述した後から有効になるのでそういう場合はライブラリの直前にOPTION STRICTを記述してテストコードはそれより前の行に記述すれば問題ありません。

それから実数型の演算速度が速くなったため整数演算は相対的に遅くなっている感じです。 FOR～NEXTのループカウンタが実数型変数だとA=A+1よりA%=A%+1の方が遅いくらいです。（カウンタが整数型変数だとA%=A%+1の方が速い） FOR I=1 TO 10000000:A=A+1:NEXTよりもFOR I=1 TO 10000000:A%=A%+1:NEXTの方が遅いけどFOR I%=1 TO 10000000:A=A+1:NEXTよりもFOR I%=1 TO 10000000:A%=A%+1:NEXTの方が速いということです。 ver.3.1.0ではループカウンタの型によって処理時間が異なるもののA%=A%+1の方がA=A+1よりも速かったです。

あとver.3.1.0で不可解だったA=A+1よりINC Aの方が遅いとか除算より乗算の方が遅いとかいう点が変わったのかも調べてみました。 1回あたりの平均処理時間（計測プログラムは4/30の私の活動を参照） A=A+1　345ナノ秒　→　285ナノ秒 INC A　581ナノ秒　→　551ナノ秒 A=B*5　559ナノ秒　→　390ナノ秒 A=B/5　402ナノ秒　→　283ナノ秒 全体的に速くなっていますがこれら2つの不可解な点は相変わらずのようです。 ちなみにver.3.2.0ですべての処理が速くなっているということはなくFOR～NEXTループは逆に遅くなっています。

ver.3.2.0でSPEED TESTを実行してみました。 ver.3.1.0と比べて全体的に速くなっているようです。 たしざん　　512804 → 541948 PRINTぶん 143829 → 151421 スプライトいどう257266 → 273725 ラインびょうが 60896 → 69930

けいさんへ SQRTはSQRと比べて速度が遅いという違いがあります。 なぜここまでの速度差が発生するのかは分かりませんが。

上記の補足ですが、逆算すればいいだけなので1/100単位であっても1/1000秒単位であってもMAINCNTで全く問題ないです。

ご自由に使ってください

最速のFOR～NEXTによる1000万回ループプログラムだと499フレームですね。 M%=MAINCNT A%=1 FOR I%=A%TO 10000000NEXT ?MAINCNT-M% WHILE～WENDやREPEAT～UNTILでも同じようにループ内でインクリメント処理を行い最速の1000万回ループを作ってみたところWHILE～WENDが442フレーム、REPEAT～UNTILが391フレームでした。 確かにFOR～NEXTは遅いですが、この「最速」という条件で統一するならばREPEAT～UNTILと比べても速度は1.27倍くらいの違いとなります。

マイク命令を使えば1/100秒単位や1/1000秒単位で計測可能なタイマーは作れますが、タッチやボタンで停止する限りは1/60秒（1フレーム）単位でしか計測できません。 作りたいものがストップウォッチではなくレースゲームなどののタイム計測であればゴール通過後の座標と速度からゴールライン上を通る瞬間のタイムを逆算することで擬似的に1/100秒や1/1000秒単位で計測可能です。

三角関数を使ってスプライトを変形させてポリゴン表示はできなくはないけどGTRIを使って表示する方がお手軽なのでオススメです。 ポリゴンの前にワイヤーフレームに挑戦するのが良いかもしれません。

FPSを求める最も簡単な方法は1秒間（60フレーム）に何回実行できるかをカウントすることです。 INC FPS:IF MAINCNT-CNT>59 THEN LOCATE 0,0:?"FPS";FPS,:FPS=0:CNT=MAINCNT これをメインループの適当な場所に入れれば画面の左上にFPSを表示できます。 1秒間隔ではつまらないとか0.1fps単位で求めたいというのであれば私の自活からFPS関数を探してそれを参考にしてみてください。

うえこうさんへ 使って頂けるだけで十分なのでそれ以上は望みません。 とはいえスペシャルサンクスへの掲載は大歓迎です。 あと改変等も自由に行って問題ありません。

うえこうさんへ A=2、かつ、B=4を判定したい場合にA==2 && B==4 と記述するのがベターでA==2 AND B==4 でも問題ないというのが私の考えです。 A=2、かつ、B=4を判定したい場合にA AND B と記述すると明らかに間違いですが、A && B としても正しくはありません。 A && Bが正しく動作するのはAが0もしくは2という値を取り、Bが0もしくは4という値を取るときのみだからです。 したがって、IF文が正しく動作しないという場合はANDを&&に変えれば解決できるという単純なものではなく比較演算子を省略しないのがベストということです。 そして、みき★さんも書かれていますがANDで正常に動作しない場合もあるので比較演算子を省略しない場合でも&&を使うのがベターです。

イカさんへ 「&&は論理演算子」「ANDはビット演算子」という違いがあります。 条件式における「かつ」を意味するのは「&&」の方だけですが、比較演算子を省略せずに書けばANDでも「かつ」の役割をすることができます。 &&とANDは速度面で&&の方が速いというだけではなく複数の条件式を「かつ」を使って判定している場合に最初の条件式でfalseになってもANDはすべての条件式を評価するのに対して&&はそれ以降の条件式は評価しないという違いがあります。 これは速度面の違いだけではなく動作面の違いが生じる場合があります。

「BUTTON(2) AND 16」の値が16、かつ、「変数SG」の値が0 というのをそのままコーディングするだけなのでこれが余計な苦労に感じるレベルだと今は良くても今後は苦労が必至です。（この場合は「かつ」の部分はANDでも動作するけど&&がベター） ANDはビット演算以外の何物でもないのでボタン判定専用と言わない方が良いと個人的には思います。 でないと、「SPCHK()で何でANDを使うの？」という疑問が出たら答えられません。

誤解を招くので補足しておくとデジタル一眼でコンデジ以上のマクロ撮影をするにはマクロ専用のレンズが必要ですが、私はそれを持ってないためコンデジの方がマクロに強いということです。 コンデジの方がセンサーが小さいためデジタル一眼と比べて画質は劣りますがどうせ縮小するのであまり差はありません。

あきとさんへ 「&&」を勧めるのがベターですが、個人的には「(BUTTON(2) AND 16)」に比較演算子を加えて「(BUTTON(2) AND 16)==16」とします。 「0以外の値だとtrueになる」「『BUTTON(2) AND 16』は0か16のいずれかの値になる」というのが分からない状態で「&&」を勧めても結局正しい理解はできないままになりますので。

気分転換は大事ですね。 ずっと考えていても解決方法が気づかないバグでもしばらく経ってみたらあっさり気づくなんてこともあるかもしれません。 趣味でやっているものならばマイペースで自分が楽しいと思えることをやるのがベターでしょう。 私は大規模作品を作ると途中で飽きるのが目に見えているため小規模作品しか作っていません（笑）

私がMiiverseを始めたきっかけはプチコン3号のスクショを得るためです。とはいえ、今はそれ以外のものがメインになってしまっていますが（笑） mkIIを使っていた頃はデジカメが大活躍でしたね。 デジタル一眼も持っていますがコンデジの方がマクロに強いため専らコンデジばかり使っています。 マクロ切り替えをせずに自動的にマクロモードになる機種なので重宝しています。 デジカメで撮影した後はトリミングと解像度変更と色修正が必要不可欠なので撮影後の処理が少し面倒です。（ここまで気を遣ってもMiiverseのスクショ以下の画像しか得られない） まぁ公開キーのメモに使う程度ならば難しいことを考えずシャッターを押して終わりですが。