BASIC==a necessary commodity for which demand is constant

This is the example of the result. Of course you can modify fonts on GRP5 as you like.

Could you refer to the attached screenshot? I've made a command "BGPRINT" to print any sentence (but capital letters only) on any location of BG plane.

When you type letters on the keyboard or use PRINT statement, the letters will appear on text plane. Actually, character size of text plane is fixed in 8x8 and you cannot change it to 16x16. The method I can recommend is to use BG plane or Sprite plane for putting letters instead of text plane. And I think BG is better for it than Sprite, because longer sentence wastes more sprites.

Both sprite and BG already have fonts (only capital letters) and you can redraw them as you like.

The font size of SmileBASIC has been fixed in 8x8. You can make 16x16 fonts with following two methods. #1: Use "WIDTH 16" to enlarge text fonts. #2: Apply sprites or BGs as Fonts.

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

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

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

おちゃめさんがおっしゃるところの111111111111111111111111111111010が、なぜマイナス6になるのか、お分かりですか? 2進数の下位ビットから数えてn番目のビットは、2のn-1乗の数を表すことはご存じと思います。 では、最上位ビット(最下位ビットから数えて32番目のビット)は、2の31乗を表すかと言うと、そうではなく、2の31乗をマイナスした値になります。マイナスなのは最上位ビットだけで、あとは普通にプラスです。 面倒かも知れませんが、これらを全て足してやれば、マイナス6になるのがお分かりいただけるかと。 結論を言えば、NOT N==-1-N です。

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

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

"WAIT 1" waits 1/60 second, so that if you want to wait 1 second, you should write "WAIT 60". If you want to wait T seconds, you should write "WAIT T*60".

シンプルに考えれば、敵から見て自分が右にいれば右に、左にいれば左に、上にいれば上に、下にいれば下に移動すればよいのです。 自分の座標をMX,MY、敵の座標をEX,EYとした場合、敵から見た自分の左右の向きはSGN(MX-EX)、上下の向きはSGN(MY-EY)なので、ループの中で EX=EX+SGN(MX-EX) EY=EY+SGN(MY-EY) を繰り返せば、敵は自分を追い詰めるはずです。

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

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

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

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

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

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