FFTはわりと数学知識がちゃんと無いと挫折するくらいには数学よりな仕組みなので 下手に数学の式や理論を見るよりかは、アルゴリズムとしてのFFTのコードと動きを見た方が理解がしやすかったりも。 とはいえプチコンではFFT関数でFFTはしてくれるので、みなつさんの説明な感じで使うことで、音声録音から音階までは計算できたり。 音としてFFTやデジタルの扱をちゃんと理解するなら「C言語ではじめる 音のプログラミング」をオススメしておきます （３０００円しないの図書館にお願いするよりかは個人で買うのもおすすめです、amazonにもあるし） C言語と言っても特定の処理の本の場合はあんまりC言語特化されてないので、BASICしか知らなくてもなんとなく処理が読めたりするので C言語の本もわりとおすすめです。 （「CによるフラクタルCG 」などをBASICしか知らない時代によくBASICにしてました）

FFT「高速フーリエ変換」は波にどんな周波数が含まれているかを変換してくれます。 数学としては、いろんな周波数の正弦波を合成していくと、いろんな波を表すことができます→「フーリエ級数」 そして、その波(合成波)がどんな周波数の正弦波が含まれてるかを求めるのが「フーリエ変換」 数学は連続した波を扱うけど、デジタルで扱う波はサンプリングレート(BIGだと1/32000秒)ごとの連続してない値→「離散」 離散化された波をフーリエ変換（波から含まれてる周波数を求める）するのが「離散フーリエ変換」 離散フーリエ変換をアルゴリズムによって高速にしたのが「高速フーリエ変換」 音は波なので、FFTをすることで音に含まれてる周波数が求まって、 音階は周波数なのでFFTすると音階が求まるのです。 本格的に知りたい場合は「やる夫で学ぶディジタル信号処理」を見ると分かったり挫折したりするかもです。

GRPnを GRP形式でファイルに書き出す 配列を DAT形式でファイルに書き出す GRP形式ファイルをGRPnに書き出す（形式違ってたら終了） DAT形式ファイルを配列に書き出す（形式違ってたら終了） FILESはGRPもDATも一緒に表示されて区別できない ファイル単体の詳細情報を取得する方法は無い これだとどうしてもファイル名で分けるしかなさそうという感じです。 DAT形式でなんでもかんでもアクセスできちゃうとセキュリティ的な何かって感じも。

プチコンってファイル関係が結構貧弱な感じ。 今あるファイル機能から考えると、自分が作ったプログラムのルールで書き出したファイルを、自分が作ったプログラムのルールで読み込むって感じにしか見えないところ。 FILESもちゃんとプログラムで使うにはファイル一覧以外の情報がちゃんととれなくて、公開キーダウンロードしたファイルたちの管理を、工夫でどうにかなるレベルではないのが残念なところ。 （いちおう社長トピックの追加してほしい機能には書いたけど、期待はできなさそう） 「ファイルの拡張子」ってもともと、ファイル名だけをみて中身が何かを判断できるように作られたモノなので、GRPとDATがちゃんとシステムで区別が出来ないのなら、拡張子を付けるくらいのやりかたしかなさそうな感じです。 SAVE/LOADがGRP,DAT分けしてるのにFILSEがGRP,DAT分けしないのは仕様不足な印象です。

BIG出た直後にキーボードからひらがなカタカナ変換できなかったので、スマイルツールボタンにローマ字変換プログラムを登録して、ローマ字変換プログラムはクリップボードに保存して、スマイルツール終わらせてからプチコンエディタ上で貼り付けることで、BIGでひらがなカタカナ変換プログラムを作ったことがあります（すぐあとのアップデートで公式の変換システムができちゃったけど） スマイルツールを使わないなら、スマイルツールでクリップボード経由で漢字変換を返す漢字変換プログラムを作るのもありかもです。 （作るのが大変だけど）

ゲーム中に登場するためのみんなの設定は「ゲーム中のみんなの設定」みたいな別のお絵かきトピックでまとめたほうがいいですよ。 すでに書いてある人もまた書いてもらう感じにしてもらって、そのお絵かきトピックだけ見れば、みんながみんなの設定を見ることが出来るという感じ。

ちなみに「まとまった処理を呼び出す」というやりかたの呼び方は、いろんなプログラムでいろんな呼ばれ方をしていて、 BASICで GOSUBで呼ぶのを「サブルーチン」ってよく言われます。 プチコンのDEFは「ユーザ定義命令」や「ユーザ定義関数」とよばれたりして、「関数」とよばれることが多いです プチコン以外だとだいたいは「関数」ってよばれていて、クラス系は「メソッド」だったり「コンストラクタ」だったり、呼び方はさまざまなのです。 まとまった処理を呼び出して戻るという「やりかた」はどの世界でも変わらないので、 「この処理まとめられそうだな」って思ったら、サブルーチンなりDEFなりで分けるようにすると、プログラムが読みやすくなって修正しやすくなります。

サブルーチンの目的としては ・まとまった処理を別にまとめて書ける ・何度も呼ぶ処理をいちいち書かなくてすむ という感じ。 だにえるさんのコードの @SUB は @MAIN の中にそのまま書くこともできるけど、 @MAINの中身が長くなってしまって、@MAINは何をする処理なんだろうってわけわからなくなるので、 それを @SUBで分けると、@MAINがすっきりして見やすくなります。 そして、@SUBはボタンの入力で XとYを変更する処理なので、@MENUみたいな別の処理で使いたい場合、@SUBを呼び出せばまた同じコードを書かなくて済みます。 プログラムを作るときは「主人公の処理」「敵の処理」「メニューの処理」など、目的によって分けることが多いので、そういう処理をサブルーチンで分けると、プログラムが見やすくなって修正しやすくなります。

中学生での高校数学は「数学読本」がおすすめだったりします。 ６巻セットだけど２巻目がグラフや三角関数なのでおすすめ。 どんな本かはわかりやすくレビューしてる人がいたのでこんな感じ。 http://dpfrst.seesaa.net/article/15324634.html 買うにはちょっと高いので、学校の図書室・図書館が自由に使えるなら本を探してみるか、図書の先生に言えば調べてくれたり図書館用に注文してくれたりします。 学校の図書室が使えないなら地域の図書館で同じように聞いてみるとあるかもしれません。 でもプチコンで高校数学を使うにしても、円の動きと三角関数とか、ベクトルあたりになりそうかも。

ちなみに一応チェックはしてるけど、ちゃんとレスできないくらいには忙しいので最新トピックには足跡のこさず状態。（毎日通知はさすがにしんどいので） 多少仕事楽になってきたら作っちゃおうかなと実は思ってたけど、ちょっとずつ進んできてそうなので、あとはがんばってくださいという感じです。

プログラムって上から順番にしか実行できないのです（超大事） 上から順番にしか実行できないのを、制御するための処理が GOTO だったり、あまさとしおんさんが書いている制御構文だったりします。 こりんごさんが書いているように、次はどこを実行するかを指定するのに「@」を付けた名前を書くことで「ラベル」になって、GOTOやGOSUBで指定できるようになります GOSUBでラベルに飛んだらRETURNでGOSUBを呼んだ次に戻ってきます。 ラベルで指定する以外にも、IF文は条件が成立するかしないかで ELSEやENDIFの次が実行できるようになるし FOR-NEXTもカウント中はNEXTが実行されたらFORまで戻ります。 こういった制御で次に実行する処理はプログラムのどこかを制御することで いろいろなプログラムが作れるようになります

プチコンって、プログラムを勉強したい、ゲームを作りたい、って他に 他人の作ったゲームを遊びたいってのにも向いているので、 気になるなら買っておくことをオススメします。 今はプログラム分からなくても、将来プログラムが分かってきたときに 3DSにプチコン買っていたから触ってみようって時がくるかもしれない？ ※大昔のファミコンのBASICを持っていたけど、ちゃんとプログラム出来るようになったのは数年後だった経験あります

プログラムって、そのプログラム環境で呼び出せる命令の組み合わせのパズルのようなもので、 計算した結果を覚えたり、順番にしか実行できないプログラムを条件次第で順番を戻したり進ませたり（ループや分岐）しかできないのです。 プチコンだと3DSのボタンやタッチパネルの情報が取り出せて、画面に文字を出せたり、画像を書いたり、16x16ドットの画像を組み合わせて背景にしたり動かしたり、音を組み合わせた音楽を鳴らせたりもできるので そういった単純な命令を組み合わせてゲームが出来るという感じです。 みんなが作っているゲームやプログラムも同じように命令を組み合わせてるだけなので、 他の人のプログラムを見て、組み合わせのやりかたを知っていくと、プログラムがいろいろとできるようになってきます。

プチコンマガジンvol２の予感！？

ちなみに日付時刻計算は、Excelだと 1899年を基準とした日のカウント（時は浮動小数なので厳密な秒の計算はちょっと怖い） 他のシステムは1970年を基準とした秒（こっちは秒がオーバーフローする2038年問題がある） どちらも、長い期間を計算するのか、秒の精度を期待するのか用途が違うので、どっちが良いというのは用途次第だったりします。 １２行目まで年月が同じになるまで日を足してるけど、１２行目は AD=AD+NM(SY,ST)-SD+GD-1 だと 開始月の日をさらに足してるので AD=AD-SD-1+GD の、すでに足し込んでいる開始日を引くのと、終了月の日を足すのでいいのかも。

作りとしては、年月が違っていたら、年月が一致するまで日を足し込んで日に変換して変数ADへ代入して、あとで時に変換。 時刻は秒変換して変数ATに代入して、年月日が違えば１日分加算 あとはHをADとATから、M、SをATから変換（FLOORはDIVを使った方がすっきりするかも） （変数ADが年月違いのときに初期化されなくて２回目からおかしくなるはずなので、TCAL入った段階で初期化したほうがよさげ） 日時変換はほんとややこしいので、比較される日時どうしを計算するのではなく、いったんそれぞれある基準からの秒や日などに変換してから、その値同士で計算して、求まった秒を日時に計算する方法のほうが一般的だったりします。（１日の長さは86400秒固定なのであとで計算できる） どうしても今の方法を使うなら、TCALの計算途中で変数をPRINTして、いろんな日付を渡して動きをチェックしたほうがいかも

ステップ実行じゃなくて次のデバッガ呼び出しまで実行かassertくらい。 プチコン上のエディタ起動シーケンスとしては、ひとまずスマイルツールからいろいろがんばれそうかもってのと（デバッガが実装できるかは微妙）、 ログもあるので、しばらくしたらトピックを閉じる方向で。

New3DS手に入れたのでちょっとずつ再開中。 旧3DSとくらべて全然やるきがでる！（主に実行のスタートボタン位置） スマイルツール登録するとエラーメッセージからSLOT 4っぽいことはわかるけど、他のスロットではできるVAR("4:AAA")みたいな変数参照ができなかったけど、多分ちゃんとしたやりかたがありそう。（COMMON なんちゃらをまだ試してない） スマイルツールでエディタ起動→SLOT 0 編集→エディタ上でSLOT 0実行→SLOT 1にコードまるまるコピーして EXEC 1 → メインループで SLOT 4の EDITOR_DEBBUGER() 呼び出し、L+Rなどで実行中断 → メモリ見てステップ実行など、修正するなら SLOT 1に空コード読み込みして最初に戻る って流れが SLOT 4を呼び出せないとできなさそう。

まずはこれから作ろうとする戦闘の流れをイメージしてどんなふうになるか把握したほうがいいかも。（そのためのフローチャート） 前のスレッドにざっと書いたけど、今回のバトルは超おおざっぱに言えばフィールドが広い将棋で、コマを自分のターンに全部動すけどコマ移動ごとに移動後のコマンド実行なので、 コマ移動して相手が目の前にいるなどで戦闘が発生したら、コマを移動した側がとりあえず先に攻撃する、って感じ。 ベースが出来て動いてしまえば、すばやさとか特殊能力とかでのバトルダメージ計算はあとでいくらでもサブルーチンを誰でも変更できるし、追加要素（クラフトとか）がバトルに影響与えることも出来るという感じ。

FE系バトルはフィールド移動してのバトルなので、バトル処理もだいたい↑と同じ フィールドもあわせてどのキャラ（主人公、敵、BG）がどのGRP使うかの定義も必要なのでその辺の変数も追加かな。 セーブが必要ならバトルステータス系の主人公のと、マップ用のイベントフラグあたりを書き出し・読み込みすれば良い感じ マップとNPCとイベント定義はラベルで範囲指定してコピーすれば取り込める感じ。 イベントフラグはID決めて、誰が何番から何番まで使うとか、宝箱用フラグはまとめておくとか、大事なストーリー用のフラグはみんなで何番は何って決めるとか。 この辺まで決めておけばベースのプログラムまでは出来ると思う。