恐らく高速化のため256bytesずつコピーだと思うので、バグと言ってしまうのはちょっとかわいそうかなと。 (実数なら4つずつコピーするって考えれば挙動は理解できると思います) マニュアルにはきちんと書いておくべきだと思いますけども。 デフォルトでmemmoveな挙動にしてしまうと大分パフォーマンスに影響でますし…。 文字列の方はアライメントの影響でまとめてコピーできなくて挙動が変わったんでしょうね。

＞おちゃめさん チェック漏れてました、お恥ずかしい。 確認ありがとうございます:)

以前、浮動小数点数と整数x2の相互変換関数作ったことあります。 【 4K4PJXP3 】 今だとCLASSIFYがあるから、nan/inf周りはそっち使ったほうがスマートなんだけど、参考になれば。 でもMIKIさんと同じく、こんな面倒なことをするより整数配列/文字列使うほうが簡単だし速いっす。

単純に誤差ですかね。 ラジアンってπ含むのでどうしても誤差は出ちゃいます。 この場合だとSGNをいじっちゃうのが楽かな？ DEF SGN2(X) IF ABS(X)<POW(2,-52) THEN RETURN 0 RETURN SGN(X) END

間違えた！最後の Y1=Y1+(DX*2)/L は Y1=Y1+(DY*2)/L が正しいです。

SIN/COSが苦手ならいっそ避けちゃって、 中学生なら三平方の定理使ってやってみるとかー。 (習ってるよね？) '2点間の距離を求める DX=X2-X1:DY=Y2-Y1 L=SQR(DX*DX+DY*DY) '長さを一定(今回は2ドット分)にしてX2,Y2に近づくようにX1,Y1を移動 X1=X1+(DX*2)/L Y1=Y1+(DX*2)/L 尚、点が重なってる時はエラーになるからそこは気をつけてね:)

==より<=や>=の方が速かったりするので REPEAT:I=I+1:UNTIL I>=1000000 とか書くほうが速いです…といってもループ回数が数万超えるようなケースじゃないと差はわかんないでしょうけども:) 配列を1次元にするかどうかは、ある領域を左上から順に見ていくことが良くあるかどうかで決まる気がします。 お絵かきツールで四角描画するようなルーチンみたいなの。 アクションゲームだとそゆことあんまりやらないから、座標からインデックスに変換する手間もあってそれほど高速化効かないんじゃないかなーと。

@LOOP VSYNC '処理 GCLS '描画 GOTO @LOOP システム内部で裏画面にバッファに描画・フリップが行われているので、処理がある程度重くなるとGCLSのあたりで画面更新が行われちゃって真っ暗なままになることがあるんですが、それかも。 グラフィック関連の命令はデフォルトで512x512全体描画なんですが、GCLSなんかは上画面なら400x240で十分なので、GCLIPで範囲指定しておくと結構軽くなります。それで改善するかも。

ごめん！ちょっと嘘つきました。 VAR X[0]:?LEN(X)はエラーにならないですね、なんか間違えて覚えてました。宣言のとこ通るまではきちんと初期化されないということには変りないので、エラー原因とかは上で書いた通りですが。 あと宣言してるだけで確保しちゃうとメモリ使用量の面で問題がでそうだから、仕様としては妥当なとこだと思いますよ:)

半分くらいはOPTION STRICTで解決するけど、もう一点ハマりやすい仕様があって。 配列定義は実行された時に初めて領域が確保されます。それまでは要素数0の配列扱い。で、要素数が0の配列は何故かLENできないので下のプログラムはタイプミスマッチ…このエラーはどうなのかって感はあるけど。 FUNC VAR X[10] DEF FUNC ?LEN(X) END ライブラリとか作る場合、この仕様にハマりがち。 サブルーチンか初期化関数を作って使う前に初期化してもらうのが基本。

うん、普段はあんまり気にしなくてもいいよ。 こういう細かな高速化は、速度が問題になってもうどうにもならなくなった時に悪あがきでやるものだから:) それまでは見た目が綺麗で読みやすい書き方が正解。 ただ大きなプログラムじゃなくて、計算回数が問題かな。 例えば、自キャラ動かす処理だと1秒間に60回、X座標とY座標で2倍の120回くらい計算するわけだけど、同じような処理を敵にもする場合、敵が1000匹居たら120,000回くらい計算することになるよね。 これくらいの回数だとちょっと高速化が必要になってきそうでしょ。 プログラムの大きさと計算回数はあんまり関係ないよー。

INC AとA=A+1実験しなおしてみては。 今までずっとA=A+1の方が速かったはず。 手元のNew3DSで試したけど、A=A+1の方が速かったよ。 ノーマル3DSでも同じだったと思うけど…。 ちなみに A=A+1とA=A+2の差は無い、INC AとINC A,2も同じくらい。 INCの方が確実に速くなるのは配列使ったときだけじゃないかな。 A[0]=A[0]+1だと2回配列にアクセスすることになるので遅いっていう。

画像データをプログラムに埋め込む処理をPC側でやろうとしたのだけど、P/SEND2で処理するとき…ブラウザでテキストファイルを読んだ時にサロゲートペアがちゃんと対になってないところはU+FFFDに変換されるようでうまくいかず。 対応するとなるとバイナリで読んで自前でごにょごにょする必要があって大変やりがいがあるので、放置かな。 次のバージョン作ることがあったら考えよ…。

アイコンとか基本的なデザインを固めた。とりあえずこんな感じで一通り描画できるところまで早く持っていきたい。 UI周りは切り替え無しのGRP1面だけなんだけど、チラつきなんとかなるといいなぁ。 毎フレーム全描画＋GRP切り替えが一番楽なんだけど、描画コストが無視できないし、GRPに空きがある方がいろいろと助かる。

P/PreProcessor v0.2.2 【Q34JK43D】 FINALIZE呼び出し後にユーザ指定の命令を呼び出せるようにした。 AT_FIN "FUNC"で命令を登録するとFINALIZE実行後にFUNCが実行される(登録とは逆順) プリプロセス中に確保した配列などをクリアする方法が欲しくなったので追加。 間が空いてしまったけど、お絵かきプログラムはようやく土台となるライブラリがそろった所。 ファイル数が増えてきたのでP/SENDをアップデートして複数ファイル送れるようにしたい……けどここで他のことやったら頓挫しそうなので耐える:P

透明色考えると実際の色数は 2^15+1 もしくは 32^3+1 ですかね:)

すごく小さいフォントライブラリ。なんちゃってアンチエイリアス風。 【 2VNN3CJ 】 0_PIMFNT.PRGをSLOT0に読み込んで実行すると、SLOT3に完成プログラムが出力されるので、万が一使いたい場合はSLOT3の54行目あたりからコピペで。 デザイン考えてる時に、とりあえず小さいフォント必要になりそうだったので作成。 効果があるやつもあったけれども、結局アンチエイリアス無い方が見やすいんじゃないか説…。

まだハリボテだけど、こんな感じにしようかな的なスクショ。 色々計算した感じ6Mくらいメモリを使うため、あんまり断片化するような設計だとまずいよなーということで、やりたいこと洗い出すために見た目とか色々固め中。 作り直し中のUIライブラリはまだ半分くらいだけど、ようやく方針決まったかな？

微妙にバージョン上がってます。 以後たぶんこちらの開発日記に。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0evIYhZPg

P/PreProcessor v0.2.1 【4K3XKXXD】 プリプロセッサ？的なやつ。とりあえず使えてるけどまだまだベータ。 ■インラインコマンド、文字列以外をSTR$()で自動的に変換してくれるように変更 {{STR$(I)}}とか書くの面倒になったので追加した。 下みたいに書くと多重定義がある程度回避できる。 ライブラリでユーザーに見せたいグローバル変数や定数を、ユーザーが好みの位置におけるようにもなるし結構便利。 REM:DEF INCLUDE_GUARD REM: IF INCLUDE_GUARD THEN RETURN ... REM: INCLUDE_GUARD=1 REM:END:INCLUDE_GUARD