別スロットのグローバル配列は、そのままでは使えない仕様なのか、なるほど。

3は小さなボタン類に向いていると思います。 1は四角など単純な形の大きなボタン類に。 複雑な形のボタン類なら2で。色は別のGPAGEに持たせる等すれば判定処理が楽になるかと思います。

それ以上の良いアルゴリズムは思い浮かびませんね。 比重の大きいものが前に来やすいようにすると効率が良いと思います。

疑似視差バリアを利用した立体視対応な線画がサクッと描ける関数をちびちび作成中。

ダイレクトにネタをバラしてしまうのも無粋かとは思ったのですが、小中学生の子供が必死に解けない問題に挑み続けるところを想像すると可哀想に思えたので書いちゃいました。

これ、初期配置がT字ミノな今の仕様だと本当に絶対不可能ですね。

「プチコンmkII 初心者講座」で検索すると出る公式解説サイトは、とても分かりやすいのですが、いかんせんプチコン3号と細かいところが色々と違うんですよね。 まあある程度は参考になるかと思いますが…。 開発会社は今は色々忙しくて初心者向け講座まで手が出せないそうですが、プチコン3号向けの講座も作りたいとは言っているので、それを待つのも手かもしれません。

色々小ネタも挟まってて面白かったです。例の呪文にもバッチリ対応してましたね…。

一行関数にしたバージョンはこちら。構文解析して色をつけてくれるので、少しだけ読みやすい。

先頭でAに代入した数を2進数表記にするワンライナー(1行プログラム)。 短さ最優先のため可読性(読みやすさ)は最悪！

&&とANDの違いが分かりにくい根本的な理由は、true/falseが数字と一緒くたに扱われている(boolean型として独立していない)ためと思います。 もっとも、そこを逆用したテクニック、個人的には好きなんですけどね。

昨日、けい さんの投稿で盛り上がっていた && と AND の違いのお話。乗り遅れたので別投稿で失礼します。 &&は短絡評価を行うという点や、ANDで関数が呼ばれる順序は、なかなか重要っぽいです。

そもそも「ボタンを押す長さで飛ぶ高さが変わる」という挙動自体、物理法則に反してますしね。 それっぽく、かつゲームとしても面白い挙動は非常に難しい。

なんてこった、本件、小林社長がツイッターでとっくに詳細報告済みだった。 というか普通に公式にない細かい情報がゴロゴロ転がってるし。

自己解決。 new3DSでは約0.8ミリ秒弱のウェイトを入れることで、チラつきが消えました。 つまり描画更新がVSYNC(WAIT)から0.8ms後(new3DS時)にズレていて、CLSが描画更新の前に来ていると。 修正版がくれば、ウェイトなしでVSYNC→CLS→PRINTとしても、チラつきは出なくなるはず。

本来このコード、VSYNC(WAIT)から1フレーム未満でCLS→PRINTを実行しているので表示はチラつかない筈。 公式サイトの障害情報にある描画同期のズレによるものか、それともコンソールの仕様なのか、どちらだろう。

他所で少し話題になっていたが、どうも配列に関してはポインタ渡しが出来るっぽい。 スクショはその検証結果。

例えるなら、クラス定義+そのインスタンスの組が(main含め)4つあるようなもの、ってとこでしょうか。なかなか融通が利きそう。

GOSUBは、classはおろかユーザ定義関数すらない昔のBASICの名残といったところ。 内容的にはGOTOの親戚といったところで、GOTOと違ってサブルーチン内の処理が終了したら呼出元に戻れるのがGOTOと比較してのメリットでしたが。 プチコン3号ではユーザ定義関数がGOSUBの上位互換の機能として存在するので、あまり使う旨みもない気がします。 プチコン3号ではCALLよりGOSUBの方が処理が速いようなので、少しでも処理速度を稼ぎたい時は使うことになるのかも。

関数内でもグローバル変数を参照・書き換えしたいケースもあるので仕方ないとは思うのですが、問題なのは VALUE=1 DEF FUNC VER VALUE 　： END と、関数内で明示的にローカル変数宣言をしようとしても、グローバル変数として既に定義されている変数名を使うと Duplicate variable エラーになってしまう点に思えます。 グローバル変数と同名のローカル変数が作れれば、不便さはなくなるかな、と。