ランバートでシェーディングしたキューブ1個で4FPS程度か。ワイヤーフレームなら20から30FPS程度は出るが、ダブルバッファリングなんぞは無理なので、容赦なくちらつく。ワイヤーフレームは線引き関数で一発だが、ポリゴン面のラスタライズは自前でチマチマやるしか。

“あわよくば”、これでdemoでも作ってみるかなと、ここ数日書いてみて、プチコンでリアルタイムレンダリングさせてみたが、重すぎる。当初の目標ではper pixelシェーディングで色々やってみたかったが、これ以上重くなるとリアルタイムとは呼べなくなりそうだ。
DSiよりもパワーのある3DSだとより高速になっているのかと思ったが、そうでもなかったようで。多分同じ速さで動作しているのかね。リミッタ外せないのかな。

ハードウェアの支援など何一つ無い、低速なグラフィックへの読み書きなので、oldschoolな2Dのdemoも結構厳しいのではないだろうか。スプライトもサターン並みに変形出来れば、利用出来たのだろうけれど、このソフトはそういうコンセプトではない。

重い以外にも相当制約が厳しい。
数は固定小数点のみで、精度も余裕が無くカリングがうまくいかないケースがあるし、内積などで最大最小値を超えるとオーバーフローで止まる。
グラフィックは色が256色しか扱えないので、使う色を限定してさらに間引かないと多色を扱うことすら困難。
試しに深度マップ用意しようと愚直に256*192で配列を取ったら配列の限界数を超えるし、メモリも不足する。深度マップに関しては256色ながらも下画面のバッファを活用すれば裏技的に実現できそうだが、色の読み出しが大変重そうである。Zソートしか現実的ではないかな。

さらにBASICがクセモノというか、私はベーマガ世代でもなんでもないが、昔の人はよくこんな言語使って組んでたなと関心するほどに扱いにくい。非効率的すぎる言語だ。
スコープという概念というかローカル変数なんぞ無く、漢らしく全部がグローバル変数。サブルーチン先で値（特にFOR文のカウンタ）を上書きしてぶっ壊してえらいこっちゃ。
サブルーチンに渡せる引数も無いので、仕方がなく引数用の汎用的な変数を用意してそこに値をぶち込むのだが（これも変に値を上書きして壊さないように注意しながら）、行列1個で16回のコピーが発生するのがなかなか馬鹿にならないコストだと思うし、コピーする処理を毎回書くのが面倒である。

アドレスも扱えないし、個人的にはアセンブラの方がまだマシかね。

まあ、こんな馬鹿みたいなことをやろうとしなければ、良い言語だとは思わないけれど、良いソフトだと思う。タッチパネルの仕様の所為か、結構な頻度で押した場所と違う場所が押されてしまい、変な文字が入力されて嫌なことになるのが気になるけれど。

（追記）mkIIが出たので、QRコード公開してます。