外人の 3D(FPS) ゲーム好きは異常

そのセル画っぽいの、著作権は大丈夫ですか? 他人の著作物を許可なくミバに公開するのは著作権法違反ですよ。 公開できるのは自分で描いたものや、明示的に第三者による利用が許可されているものや、直接許可を得たものなどに限られます。

dim var("a"+"8") みたいなことできたら面白いですね。 dim 命令というか宣言は、実行に先行する「コンパイルフェーズ」で処理されるので、var("a"+"8") という関数の評価はしてくれないんでしょうね。

例えば "n=8" という文字列があったとして、これを "=" で分割し "n" と "8" の文字列にします。で、 var("n") = val("8") を実行すれば n=8 と同じ結果が得られます。 data "n=8", "px=40", "p=-5.2", "name$=花" とか書いといて、一つずつ上記の手続きに当てはめれば、変数の初期化はたった一つのループに集約できますね。 read/data を使う代わりに、"n=8 px=40 py=-5.2 name$=花" という文字列を用意して、空白で分割したら同じことができる。 この文字列をファイルから読めば、ファイルから設定値を読むことが可能。 変数値の保存も、 save "txt:data", format$("n=%d px=%f py=%f name$=%s",n, px, py, name$) の一行で済む。

なんだか違う気がしてきた・・・・ やりたいことをもちょっと明確にオナシャス

いまひとつ意図不明だが、できる var("i") は 変数 i と同じ なので、 a$="i" var(a$) は 変数 i a$="j" var(a$) は 変数 j ・・・・ってことでいいのかな??????

著作権者の許可なく著作物を公開するのは違法行為。

エコーみたいなやつ ワラタ

> 変数に+1するときはこっちのほうが処理が早い だうとおおおおぉぉぉぉおぉおぉぉお!!!! inc は、配列、乗算、goto と並ぶ「激遅四天王」の一角!!! ・inc x は x=x+1 より遅い!! ・v[i] は cos(i) より遅い!! ・x*a は x/a より遅い!! ・goto は repeat until より遅い!! ただし、配列に限っては inc x[i] よりも x[i] = x[i] + 1 の方が遅くなります。(配列が最強に遅いので、配列を二回評価する後者の方が、inc の遅さを上回って更に遅い!!!)

指標を 0 開始にしたせいで逆に不便になるのが for 文の 初期値 to 終了値 1 開始なら dim x[8]: for i=1 to 8 でいいんだけど、 0 開始なら dim x[8]: for i=0 to 8-1 と -1 する必要があります。 これも例えば for i=0 repeat 8 みたいな構文にすればよかったと思う。 おっとここで (開始点、終了点) よりも (開始点, 長さ) の方が便利 という主張と繋がりましたね 真偽が 0 1 てのは、伝統だと 0 -1 だったのね。 これだと true < false になって気持ち悪いし、コーディング上も不便。 0 1 で true > false だと、フラグの立ち上がり判定が書き易い。

配列の指標を示すのが [] てのは 伝統的に basic では dim x(8) x(1) = 1 とか書いてきた。 ソースコードに f(1) とあったとき、それが配列か関数か分かりにくいってのが難点。 ただし、逆に「配列も関数も f(1) と書けてラッキー」と思う人もいるんだろうけど。 指標が 0 からというのは、dim x(8) と宣言したとき x(1) から x(8) まで使えるというのが fortran 由来の伝統。 かなり不便です。ので VB は 0 から 7 にできるオプションもあった。 instr とか mid$ とかも 0 開始なのは地味に便利です。

p && q は、p q 共に真の時 1 を返します。 basic では伝統的に p and q をこの目的に使ってきた。 なんで && が便利かというと 「p が 0 だったら q を評価しない」 ってこと。 var x[8] i=8: if i<8 && x[i]==0 then ? "foo" はエラーにならないけど i=8: if i<8 and x[i]==0 then ? "foo" はエラーになります。 p || q は p or q と似てるけど、 p が真なら q は評価しない。 i=-1 : if i<0 || x[i]==0 then ? "foo" はエラーにならず、 i=-1 : if i<0 or x[i]==0 then ? "foo" はエラーになる

line とか box とかも 幅・高さにすればいいと思うんだけど、 まあ互換性重視で座標指定になってるんでしょうね。 gload gsave は独自命令だから、設計者の趣味が出てしまったのでしょう。 この設計者の趣味、共感できる部分が多いです。 主に c から拝借した部分ですが。 && || とか配列指標 0 からとか、真偽値が 0 or 1 とか、指標が [] とか。

それは概算で求める時の話じゃなかった? >円周率=3 円じゃなくて正六角形による近似になるんだけど、概算だから問題ない。 >πは便利 小学生の塾では掛け算九九に 3.14 の段 がありますね。3.14 * 整数^2 も。 苦労して覚えても、中学で不要になる・・・ 帯分数も同じ運命。

gsave したときの幅と gload した時の幅が違うのが原因です。

> ミーバースでは公開しているのですし 「Miiverseのご利用にあたって」をみても、 この場合スクショをミバに公開するだけだとまあ問題ないのかなあと思いますが、 プチコンの公開キーは、例の「二次利用可能」という強力な条項が付いてますので、著作権者の許可なく公開キー取得したのは大きな過ちだと反省しているところです。 なお、手順は、スクショ->PCで1/3にリサイズ->petitmodem で転送->スプライトで2倍表示です。 この忍者キャラ、オトノワちゃんみたいにゲームで使う予定なのでしょうか? もし差し支えなければ御教授ください。 ここ数ヶ月コンビニで売っている「カムイ外伝」にハマっています。

涙ふきなよ つ□

えーーーと、 ? 0 or "0" だと type mismatch エラーになりますよね。 ""+0 とか "" も 0=="0" rnd("1") も同様。 smile basic では数値と文字列は厳密に区別しているので、(特殊な場合を除いては)数値と文字列の演算はエラーになります。 (特殊な場合というのは "a"*10 など) || 演算子は、数値に対する演算子と一般に信じられているので、予想としては type mismatch エラーが発生しそうなところ。 でもそうではなかったってことで、「バグじゃね?」という意見ね。 一方で、ver.3.1.0以降「文字列と数値の比較演算で3を返す」という謎の実装もあります ? ""<0 ' 3と表示 ? 0>"" 'type mismatch error これもバグっぽいけど、なにやら敢えて実装した雰囲気も漂っている

スゲー!!! どうやって計算してるの???

比較演算子ともども仕様だと思う。