F-ZERO風味のゲームを作る挑戦も、だいぶいいところまで来ました。自車とライバル車、合わせて４台のカートを同時に走らせることができます。自車とライバル車、あるいはライバル車どうしの衝突処理も行います。 よろしければ「JKK8Y4JX」の中の「HNZPTAD」をお試しください。 カートのスプライトが絶望的にヘタクソで恐縮です。おいおい改善します。

以前もそうでしたが、今回も、圧縮されたコースマップを解凍するのに、起動後40秒ほどかかります。(旧3DSの場合) また、言い忘れており恐縮ですが、自車の操作は、アナログパッドでステアリング(ハンドル)操作、Aボタンでアクセル、Bボタンでブレーキです。

自車セッティングのバリエーション、ライバル車の性格付け、BGM、SE、逆走判定など、やらなければならないことはまだありますが、まぁぼちぼちやっていきます。

私はプチコンmkIIではいくつか擬似3Dレースゲームを作りましたが30fpsと60fpsではヌルヌル感が全然違いますからね。（プチコンmkIIの性能だと私が作っている最もシンプルな方法でようやく60fpsが実現出来るレベル） （New3DS使用時ならば）プチコン3号はプチコンmkIIと比べて2、30倍は高速といってもF-ZERO系の「2軸回転タイプ」のゲームは重いですからね。 普通の方法で汎用の2軸回転プログラムを作った場合だと30fps程度が限界であるため「60fps」のこのゲームは完成が楽しみです。（ちなみにVSYNC 1を外したらNew3DSで330fps前後ありました） 私も独自の高速化の案はいくつかあるため時間があれば別のアプローチで60fpsに挑戦してみたいです。

Z軸回転を如何に速く実行するかは、プチコン3号で2軸回転を志す人々共通の悩みだと思いますが、私があるときフト思いついたのが「始めっからZ軸回転させたコースマップをグラフィック面に用意する」と言う作戦です。そんなわけで、22.5度ずつ回転させたコースマップを4枚用意し、スプライトのアトリビュート指定と組み合わせて、360度のZ軸回転をカバーします。さらにこれを、96本のスプライトをラスターとして、画面に投影します。16方位しかないので、方位の変わり目で回転がカクつくわけですが、これをラスタースクロールを使って、ある程度ゴマかしています。 言ってみれば、私のプログラムはゴマかしの集大成なんですが、今回は、我ながらうまくゴマかせたと思っています。 おちゃめさんの2軸回転高速化案も楽しみにしています。

すごいのよね…!!

実は今回最も気を付けたのは「衝突判定」です。 だって、めぐり先生から「ガシガシぶつけて遊びたい」ってご要望をいただいていましたからね。 逆送して正面衝突もできるので（たまにすり抜けますが）ぜひお試しください。

当たり判定あったのよねー！ しばらくしたら 置いてかれましたのよね。 コレすごいのよね！ 置いてかれても 追い付けるようには なりませんか？

時間がかかる処理は予め済ませておくというのは昔からある手法ですね。 私もこれによってプチコン3号よりも1万倍以上遅いポケコンのBASICで10fpsという高速（？）な擬似3Dのスキーゲームを作りました。 Z軸回転を予め済ませるという方法は思いつきましたが、GRPのサイズ制限上パターン数を増やせないのでカクつく問題があります。これをラスタースクロールで誤魔化すという手法は私は思いつきませんでした。 私が候補としている方法で（New3DSで）60fpsができるかは実際に試してみないと分からないですが、私が作るとしたらシンプルなタイムアタック専用ゲームになると思います。スーファミのF-ZEROも買ってから半年間はMUTE CITY Iのタイムアタックしかやってなかったくらいですから。（ダブル一点読みをマスターして任天堂の公式レコードを超える1分58秒31のタイムを出しました）

＞めぐり先生：ライバル車のライン取りは完璧ではないので（何せ私のプログラミングですから）自分のミスを最小限に抑えれば、ライバル車に追いつき、追い越すことは可能ですよ。実際にゲーム化するときは、そこいら辺のバランスは再調整をかけるつもりです。急コーナーとかヘアピンでは、わざとイン側の草地に突っ込んで減速し、コーナーをクリアしてコースに戻るのも手です。 ＞おちゃめさん：私も、おちゃめさんには遠く及ばないとは言え、昔のBASICには少なからず覚えがあります。昔のBASICは、SmileBASICよりもはるかに遅かったですから、時間が掛かる計算は前もってやっておいて、配列テーブルに保存しておくとかは、割と常套手段になりますよね。

やはり人を感動させるのは、限界を超えた作品ですよね。 そんなの無理って思ってるようなことが実現されていてこそ 「おおっ!! スゲー!!」 と感じる。 私などは -無理はしない -遅いのはプチコンが早くなれば済む話 がモットーなので、感動には程遠いです。 > 配列テーブルに保存しておく sin/cos とかね。 あらゆる言語で有効なこの常套手段をあっさりひっくり返してくれたプチコンには脱帽です。

プチコンの限界を超えた処理を実現する方法は、①力技 ②最適化 ③ゴマカシ のいずれかと思われ、私はもはや言うまでもなく③派です。MIKIさんやおちゃめさんは②派と思料します。私も実は②を選択すべきと思っているのですが、②には高度な数学的知見が不可欠であり、今の私にはちょっと敷居が高いかなと思いまして・・・ ちなみに、高速なSmileBASICの意外な弱点が、この配列アクセス速度なんですよね。プチコン七不思議のひとつです。

私は習得が遅い方なのでポケコンBASIC（PC-E500系）も粗方マスターするのに5年くらいかかりました。 プチコンmkIIもプチコン3号が出る頃にようやくある程度使えるようになっていた程度だし、プチコン3号は発売から2年経つものの未だにまだまだ不十分な状態です。 ポケコンとは違いプチコンは初代でもそこそこ高速だったためそれほど処理速度に拘ったプログラムは作っていません。（ポケコンではオールBASICのゲームをベーマガに投稿してDr.Dにマシン語プログラムと勘違いされるくらいの速度のものを作っていた） プチコン3号に至ってはQSPなどのリスト短縮や裏技を使った変な自作関数ばかり作っているため速度に拘ったプログラムは全然作ってないです。

速度の限界を超えた時の感動はポケコンでは多く味わってきましたが、（そこまで高速化が要求されるようなものを作って来なかったため）プチコンではあまり味わってないです。 速度の限界ではなくプチコンmkIIでは1画面プログラムの限界を超えた時の感動、プチコン3号ではQSPの限界を超えた時の感動ならば難度も味わってきました。 ただし、その手の制限付きプログラムの感動はそれに挑戦した人しか理解できないという難点があります。 別に他人に理解してもらうために作っているわけではないのですが・・・。

私はQSPに挑戦したことはありませんが、QSP完成時の感動は理解できると思います。私ばかりでなく、リソースが今とは比べ物にならないほど貧弱なハードウェアを常用していた当時の人たちは全て、同じ感動を共有できると思いますよ。

私の先のコメントは別に速度に限定しているわけではありません。 QSPはコードゴルフの一種ですよね。 amiga のメガデモもコードゴルフと言える。 コードゴルフは人を感動させ得るアートの領域まで行くと思いますね。 入力から予想できる出力と、実際の出力との間に想像を絶するような乖離があれば、それも人の心を強く動かします。 IOCCC やマンデルブロ集合などはその好例でしょう。 たらい回し関数の音楽化などもそうですね。 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTpSr38Cg ↑これの元ネタは http://d.hatena.ne.jp/aike/20111112 です。

私のコメントには言葉足らずの部分がありましたので少し（長目？）補足をしておきます。 処理の高速化にしてもリストの短縮にしろそれを行うためにはそれなりの知識や技術が必要になっています。 ただし、知識や技術というのは、ゲーム作りにおいてはそれをどのように使うかが重要だと私は考えています。でないと「絵に描いた餅」になります。 高速化できたから「今までは出来なかった表現ができるようになった」「快適に動作するようになった」というのが重要ということです。 そういう意味では「高速化」というのは選択肢を増やしてくれているだけにすぎません。 増えた選択肢を視覚的な訴えに使用すれば多くの人にそのすごさが伝わると思います。 とはいえ、高速化をしなくても問題ない場面でいくら高速化してもただの自己満足で終わります。（自己満足がいけないわけではありません）

リスト短縮はどうかというとプチコン3号では普通に作ってメモリの上限にぶち当たることはほとんど無くそういう場合はリスト短縮よりも他の部分を見直した方が遙かに有用です。 これは、プチコン3号で普通にゲーム作りをしていて処理の高速化が有効に働く場面よりもリスト短縮が有効に働く場面の方が遙かに少ないということです。 メモリが少なかったポケコンや8bit機でのプログラミング経験がある人や「コードゴルフ」に挑戦したことがある人ならばリスト短縮のメリット（すごさ）が伝わる部分があるかもしれませんが、処理の高速化と同じく特に短縮する必要性がない場面で短縮をしてもただの自己満足で終わってしまいます。 する必要もない無茶なリスト短縮によって可読性が大幅に落ちる場合も多くあり、その場合はメリットどころかデメリットになります。

同じリスト短縮であってもそれが有効活用できる場面ならばまた変わります。 1画面プログラム（QSPを含む）というサイズの上限付きプログラムは1FDに収まる範囲内でどれだけすごいことができるかというメガデモに通じるものがあるかもしれません。 ただし、QSPではメガデモとは違って視覚的な訴えは難しいです。 私が作っているQSPでは特殊なことをやっているものはほとんど無くて1KBくらいの長さになっていいのならば初心者でも作れるくらいのものばかりなので「想像を絶するレベル」には至ってないと思います。（ゲームバランス等もQSPでも手を抜いてませんが感動するレベルではないので「ここまで拘っているよ」という解説を付けて強引にアピールしているレベル） QSPのようなサイズ上限がある場合は、リスト短縮によって選択の余地が増えるというのが最大のメリットです。それについて詳しくは下記のトピックスを見てください。

https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0erQWuGiw これを読んでもらえるとQSP等のサイズ上限があるプログラムは、単に短くするだけのコードゴルフとはまた違ったすごさ（＝短くするのが目的ではなくQSPというフォーマットの中で最善を尽くす）があることが分かってもらえると思います。 選択肢が増えたものをいかに有効活用するかという点においては「高速化」も「リスト短縮」も何ら変わりがないですね。 これは1画面プログラム経験者ならばあえていう必要もないレベルの話ですが、8bit機やポケコンユーザーであっても（当時でさえこのような制限付きプログラムに興味がなかった人も結構いたため）なかなか伝わりにくいと思いました。

要約すると 高速化を行い「プチコン3号でこんなことができるんだ！」という感動をする人とリスト短縮を行い「この短さ（QSP）でこんなことができるんだ！」という感動をする人では前者の方が多いのではないのかな というだけの話です。（データがあるわけではないので私の経験やMiiverseのコメントを元にした主観ですが） 以上、長文失礼しました。

I have a question, how do you do 16x16 fonts? It would really help :)

考えてみると、このコミュ以外の場所で「QSP」と言っても、何のことか分からない人が大半と思います。翻って本コミュでは、QSPは半ば一般名詞化している、これこそ、QSPから感動を得ている人が少なからずいることの証左・・・とは言い過ぎですかね？ 想像と実際の乖離が感動を呼ぶ・・・私もMIKIさんと同意見です。ただ私の場合、狙って感動を呼ぼうとしたことはありません(＝できません)。私が考えるのは、ただ自分の作りたいものを、そこはかとなく、あたかも徒然草のように作るだけです。そんな感じで作ったプログラムですから、人に見向きもされなくて当然、運よく人に感動していただければ儲けもの、と言うのが、私の考え方です。

今回の2軸回転プログラムを作成するにあたって、実は、おちゃめさんやMIKIさん、あるいはれいさんなどからいただいたご意見を、随分参考にさせていただいております。特にMIKIさんには、私の不完全な2軸回転プログラムのせいで、三半規管に変調をきたし、×××を×××させてしまったことがございました。申し訳ございません。今回は、あの頃からすればかなり改善して、三半規管にも優しい仕様となっていると思います。

@★ωαггïøř★: Font size of SmileBASIC has been fixed in 8x8. You can enlarge text characters with "WIDTH 16".

Looking good! You've done a great job!

Thank you! I'll continue improving and target to be finalized.