プログラミングは「初心者でも簡単にできる」というわけにはいかないと思いますが、時間をかけてじっくり行えば誰でも作れるようになるのでぜひ買ってみてください。 自分が考えたゲームやツールが実際に画面上で動くのを見たら感動しますよ。

QSP MENUについて追記ですが、私がプチコンmkII、プチコン3号、プチコンBIGで公開している「すべてのプログラム」にはREM文でタイトル、更新日、バージョン、ジャンル、概要と操作説明が記録されています。 これはQSPのような小さなものも含むすべてです。 そのためQSP MENUのように簡単なランチャーソフトを作るだけでリストの情報を抽出して表示が可能になります。つまり、何も考えずに自動的にできるわけです。 自分が作ったものならばこんな感じで自動化を行うのは簡単にできますが、他の人が作ったプログラムではフォーマットを統一してない限りは無理です。 複数の人が同じようなネタを考えている場合は誰かのフォーマットに合わせる必要があります。ランチャーの自動化はこういった問題点があるため手動登録に頼るしかないでしょうね。

投稿された作品を機械的に検索可能にするのではなく人為的に可能にするならばOBONOさんが作っていたプチコン3号データベースみたいなやり方で可能です。 ただし、プチコン3号データベースはすでに新規登録ができなくなっているため今後の状況には対応できないという問題があるし、プチコン3号からではアクセスができないです。 そういう点においてはnobuさんのプチコン3号の登録型データベースプログラムは十分に価値があると思います。 ただし、この手のデータベースは登録数が増えないと意味が無いし簡単に登録可能にならないと登録が増えないという問題があります。すでに書かれているように情報がダブっている場合はどうするのかとか虚偽の内容や間違った情報に差し替えられた場合にどうするのかというのも難しいですね。 結局のところ登録そのものは分散化できても登録データの管理は一元化する必要があるでしょうね。

すでにプチコン3号に保存されているファイルの管理をしたいのか、ネット上にある情報検索をしたいのかで全然変わると思います。 前者はランチャを作ることで解決できます。私がQSPで作った簡易ランチャーソフト「QSP MENU」でもリストの中にある特定の文字列情報を元に管理が可能です。 この「QSP MENU」ではプログラムリストにREM文で記述されている簡易マニュアルの情報を読み取って画面表示を行ってくれます。 後者のネット上の情報検索（ユーザーが作った作品検索）はそういったシステムをスマブが用意してそれにプチコン3号側からアクセス可能にする必要があるためユーザーがどうにかできる問題ではないしスマブも簡単に対応するのは難しいでしょう。

あまさとしおんさんへ MEM$の256バイト制限を超えられるものはGRPしかなかったプチコンmkIIとは異なりプチコン3号は自由度や選択肢が増えたためあえてGRPを使う必要も無くなってしまいましたからね。 それに8bit整数値をそのまま記録できたプチコンmkIIとは異なり、プチコン3号のGRPは16bit整数値を符号付き32bit整数値に変換する必要があるため「データ保存用」として使い勝手が良いとは言えません。

よく使われる定型文をあらかじめ用意していてそれからも選択が可能になるとより実用的になりますね。

ANDと&&にあまり速度差がないのにORと||には明らかな速度差があるのはIF I || I THEN ～というのはIがtrueの時は2つ目のIは評価されないためですね。 もしも、IF J && I THEN ～（Jは常にfalse）だったらANDより&&の方が速くなります。

あまさとしおんさんの方法に加えてプチコンmkIIでは定番だったGRPへの保存もありますね。 1枚あたり512KBのデータを記録できるしACLSをしない限りはデータ保持が可能です。 しかし、1フレームごとに全データを保存するとなると1軸あたり16bit（2バイト）としても3軸では1フレームあたり6バイトのデータになります（実際は1軸10bitあれば問題ないけど）。1秒あたりでは360バイト、1時間ではその3600倍の1.24MBのデータになります。 一晩を8時間と仮定すると約10MB分のデータとなり圧縮しないとかなり大変です。 というか、そのデータを目視確認をするのも大変なので揺れを感知したら時間の記録と加速度センサーのデータ記録開始、揺れが終了したら記録終了が現実的でしょう。

現状で分かっていることは次の製品名が「プチコン」ではないということと64bit版のアプリであるということくらいですね。 Nintendo Switchで使用されていると思われるPakerベースの新世代Tegraですが、これにはCPUには64bit ARMプロセッサであるDenver 2.0が使用されていてSwitchも十分に対象の1つとなっていると思います。 現状ではプラットフォームが決まってないためどれにするのかを見極めてから開発を開始するものと思われます。 プチコンBIGはプラットフォームにWiiUを選択したのは個人的には失敗だったと思います。 開発終盤で生産終了がアナウンスされたのでスマブの判断が間違っていたとは言えないのですが。 とはいえ、WiiUはリモコンやヌンチャクといったユニークな周辺機器が使えるため個人的には面白いと思います。

個人的には色を使ってGSPOITで判断というのが最も簡単だと思います。（わざわざ別ページに描画しなくてもOK） ボタン等（タッチが有効な領域）をGRPで表示しているならば普通にその色を使うと良いですが、スプライトやBGで表示しているならば透明色のGRPが便利です。 透明色はRGB(0,R,G,B)で表示できます。透明だから画面には何も見えませんがしっかりと表示はされていてGSPOITで読み出すことが可能です。 RGB指定しなくても（色が255以下の値ならば）8の倍数の色（8,16,24,32など）を画面表示していれば扱いが非常に楽です。 GRPは8の倍数で丸められるため23という色で表示しても16に変わってしまうため注意です。「?23>>3<<3」とすれば「8の倍数で丸められる」という意味が分かると思います。

NOTはBUTTON関数では使われない上位のビットまで演算してしまうため「負数表示が望ましくない」と感じられるのであればNBUTTON関数はNOTを使うならばANDと併用する必要があります。 DEF NBUTTON() RETURN &1101111111111 AND NOT BUTTON() END このようにすれば正しく表示してくれますが、だにえるさんが作ったプログラムの方が短いですね。 表示ではなく判定だけ行うのであれば不要なビットを演算しても問題ないため押してないボタンを求めるにはNOTが非常に有用です。

NOTで負数になるのは整数型で演算しているためです。 プチコン3号の整数型は符号付き32bit整数型なのですがこれは補数によって負数を表現しているため最上位のbitが1の時は負数になります。 NOTやANDのようなビット演算子というのはこの32bit分をまとめて論理演算します。 したがって、NOT 1というのは 実質的にはNOT &B00000000000000000000000000000001であり、その結果は&B11111111111111111111111111111110となりこれは-2となります。

3Dだけに限らずプログラムというのは作り方（アルゴリズム等）によって速度が数倍～数10倍変わることはよくあります。 私が作った簡易地球儀QSPも普通に回転行列を使用した場合と比べると10倍くらい速くなっていると思いますが、実はこれが最適化によってさらに高速化も可能です。（QSPで収まる範囲内で高速化しているというだけ） プチコン3号でもワイヤーフレームならばそれほど重くなることはないと思うので恐らくアルゴリズムの改善やプログラムの最適化によって現状より遥かに高速化は可能だと思うので頑張ってください。

VSYNCやWAITが特別複雑な命令というわけではなく実は単純な命令や関数でも注意すべき点（思ったように動作しないパターン）が多く存在します。 数値を文字列に変換するSTR$でも実数型変数を文字列化した場合には6桁で丸められるけど整数型変数の場合は2の31乗-1までの数値が扱える（数値が小数の場合は長くなるため省略）などあるため「この命令って実はこうなんですよ」というのは非常に膨大なものになってしまいます。 VSYNCとWAITは当たり前のように使っているけど「当たり前ではない」という一例として書いてみました。

回避パターン3 規模の大きいプログラムを作る プチコン3号は実行時に仮想マシンコードへの変換という処理が行われ実行開始と実際に実行されるまでにタイムラグがあるためそれに1フレーム以上かかる場合も「回避パターン2」と同じく最初からAボタンを押していてもBUTTON(2)でのAボタン入力した瞬間が取得できないため誤動作が起きなくなります。 こんな回避パターンを考えるならば素直にVSYNCではなくWAITを使うのがベターということが分かると思います。

回避パターン2 FOR I=1 TO 30000:NEXTなどの1フレーム以上かかる処理をAボタン入力待ちルーチンより前に記述する これによって実行開始時にすでにAボタンを押している場合にBUTTON(2)でAボタンを入力した瞬間が取得できないためAボタン入力待ちルーチンのREPEAT～UNTILを抜ける条件を満たすことができず、一旦離して再びAボタンを押す必要がありAボタン入力待ちが正しく動作するようになります。

ここまで理解できていればタイトル画面表示時にREPEAT VSYNC UNTIL BUTTON(2)==#AとしてAボタン入力待ちを行っている際にRUN＋Aボタンでの誤動作回避も簡単にできます。 回避パターン1 VSYNC 0（0でなくても任意の数字でOK）をAボタン入力待ちより前に入れる 本来はスルーされるVSYNC 0であってもVSYNCの起点においては有用であるためそこが起点となり、Aボタン入力待ちルーチンの中にあるVSYNCが正しく動作します。

例えばVSYNC 300がプログラムの先頭にある場合はプログラムに依存します。 前回実行したプログラムにVSYNCが含まれていてそれを中断してすぐに実行すれば約300フレームの待ちとなります。 M=MAINCNT VSYNC 300 IF MAINCNT-M THEN ?"あなたは、前回中断して5秒以内にこのプログラムを実行しましたね？" このプログラムを一旦実行して再実行してみてください。 VSYNCはプログラムそのものを前回実行したときであってもそれが前回のVSYNCとなり起点となるためこのように前回実行した中断してからの時間も判定が可能です。 つまり、VSYNCを正しく理解するには起点がどこにあるのかを理解する必要があるということです。

入門講座の方は以前修正したものがきちんと反映されてなかったのでこちらで補足しておきます。（現在はすでに反映済み） VSYNCは前回のVSYNCを起点として指定フレームほど待つ命令です。 ここで「最初のVSYNCは起点が無いから無視される」という考えの人もいますが、それは正しくありません。 「前回VSYNC」というのはあくまで「前回VSYNC」なのです。

（続き） 上記については詳しくは私のプチコン3号入門講座で書いていますが、初心者に教える場合は「待ちたいならばWAIT」「タイミングを取りたいならばVSYNC」で良いので実は何も知らない初心者の方が逆に両者の使い分けを理解しやすいかもしれません。 もちろん、VSYNCの特性を理解している人や自分のプログラムでは問題ないことを分かってREPEAT VSYNC UNTIL BUTTON(2)==#Aと記述するのは何ら問題はないですよ。