マップ情報のラベルがネストされてローカルラベルっぽくしてるけど、マップ２つめを定義するとMAP_STATUSが二重定義なっちゃうのでローカルラベルっぽいの消すか定義固定にするか拡張予定ならデータ数か終端文字定義するかに期待。 マップIDも担当によって10～19までとか決めればマップとメッセージファイルのマップラベル範囲だけ取り込むだけなので開発行けそうな予感 アイテムは配列に入れてるけど配列の順番かえちゃダメなのコメントに書いた方がいいかも（DATA位置がIDになるのでずれたらいろいろ大変）

（プロジェクト全体を把握してまとめる人が居なかったり、プログラムをみんなで分担するためにみんなのサブルーチン管理や呼び出しするベースプログラムと共通データとのインタフェースの話が出てなかったりするけど、まだ様子見）

BIG側にいろいろ書いたけど、大人数開発系がどんな感じに完成するか気になるので顔出ししてみる（参加はしてません） ※プロジェクト全体がうまくいってる間は見てるだけ

ARYOP に論理演算系のオプションがあればいいんじゃないかなーって思うけど、 そもそもサウンド用な目的だとそんな感じには使わないからしょうがないのかなぁーって。 ※一応有料オプションだし、ARYOP前提なプログラムだらけになっちゃっても実行できない人いそうだし

すでに十分の人がいると思うので下手に人増やすよりかは今の人たちをとりまとめるのに期待しておきますね。 ※参加表明してないですよ どんな感じに完成するか気になるので適度にトピックや投稿コメントは見させてもらいますね。

すっごいおおざっぱに言っちゃうと、 コンピュータ上のCPUがプログラムを動かすには機械語だけだった時代があって、 それを人間が読みやすくするためにアセンブリ言語の時代になって もっと読みやすくしたのがBASIC言語の時代という流れ。 そんな時代はファイルを扱うのが簡単じゃなかったり、ファイルを覚える容量が全然無かったけど、BASICの時代になってようやくファイルもちゃんと扱えるようになってきたのです。 なのでBASICにはアセンブリ時代のdata領域を読み出す仕組みのようなのと、大容量のファイルを読み込む仕組みがどっちともあるのです。 たくさんデータがあるならファイルにした方が扱いやすいけど DATA/READだととりあえずコードに書いてすぐ動かせるBASICのメリットがあるのです。 でも今の時代はDATA定義をREADで読み込む仕組みじゃなくて、DATAがそのまま使える感じかなぁ

ちなみに、土台をいつまで作ろうとか、絵と音楽をいつまで作ろうとか決めるのが結構大事だったりも。 絵と音楽とプログラムの人は、何の絵（仲間、町人、建物、敵、タイトル、特定キャラなど）と、どのシーンの音楽（フィールド、戦闘、街、城、中ボス、ラスボス、特定のシーンなど）と、先に作っておいてもいいけど結構細かいところまで決まってないと作れないので、土台決める人が最初のうち大変かもです。 スプラトゥーン２や宿題で忙しくなるかもしれないけど、夏休みが終わるまでを完成目標にしてみるのがいいかもです。（自由研究の題材にもできそう？） ※ちなみに残り２ヶ月しかないので、本気で作るとなるとかなり大変なスケジュール

プログラム作る人、絵を作る人、音楽作る人、いろいろ考える人、と分かれてるけど プログラム作る人が最初から最後まで関わるという意味でも一番大変なので、いろいろ考える人はまずは本当に土台となるものを決めた方がいいかも。 土台が決まれば絵も音楽も作れるし、プログラム作る人もまずは簡単な操作できるモノが作れるはず。（まずはプチコン内蔵の画像で移動できたりとか） イベントシーンとかオープニングとか戦闘とか、画面が違うモノは基本的に違うプログラム(DEFとかGOSUBとか)なので まったく別に作らないといけなくなるけど、そこは担当を分けて作れるのでプログラム分担できるはず。 一番大変なのは、みんなが作ったプログラムをまとめる人なので、そういうプログラムを作った人ががんばるか、 そういうプログラムを作ってみたいって人が担当するといいかもです。

３号の方がかなり盛り上がってるので一通りログ（トピック、お絵かき）確認してきたけど、 BIGと３号って分け方じゃなくて、まずは３号盛り上がってるので３号で完成させてみて、そのあとにBIG対応って感じがいいんじゃないかなーって思うのです。 ※やってみるとわかるけど、２本まったく別々のプロジェクトをまとめるのはかなり大変 作るゲームもRPG＋独自の戦闘な感じみたいなので、まずはお絵かき投稿のコメント作るものを決めて 決まったのを仕様書としてどこかにまとめておいた方がいいかもです。 ※miiverse だとログ流れるの早いから、テキストだけ書いた公開キーがあったほうがよさげ（プチコンで漢字入力めんどいけど）

ちなみにメモリの解放っていう話だと、たぶんプチコンはDEFの中も含めてローカルもグローバルも変数はメモリ上にずっと領域を持っているので、DEF用の変数が余計に確保されているだけな感じ。 他の言語のローカルと同じ感じで、DEFに入ると0初期化されて（これは言語によりけり）、DEFの外からはアクセスできないので解放されるように見えている感じ。 DEF関数が１つのやりたいことを処理するなら、本来はローカル変数だけを使って処理してあげるのが良いけど、プチコンというかBASICはわりとグローバル変数をアクセスできたり、グローバル前提なのもあるので、使い方次第ってところです。 ※DEFで処理を完結させるのは「モジュール化」の考え

・DEFの中でVAR宣言しなかったらグローバル変数が使われる ・DEFの中でVAR宣言するとDEFの中でしか使えない（ローカル変数） ・DEFの外の宣言（グローバル変数）と変数名が同じでも大丈夫 FOR X=0 TO 10 みたいなループの中で、DEFの中でもFORでXを使う場合、DEFの外のXが参照されておかしいことになっちゃうので DEFの中でVAR Xとしてローカル変数にしておかしな動きにしないようにするのが便利な使い方です。 （特に短い名前だとどこかで変数名同じの使っちゃうことあるからおかしくなる）

PAINTする前に変更比較用にいったん画面覚えて、塗りつぶした後に変更前と全pixel比較して、変更された個数によって配列に覚えるのか、高さx幅やだけを覚えるのかすればundo bufferはGRPページ全部覚えなくてもいけそうだけど、VRAMアクセス遅いのでどのくらい時間かかるかは気になるところです。 プチコンの動的配列系（文字列含む）って、どうもメモリ連続の配列じゃないっぽかったり、配列要素変更する場合（文字列の変更も）に新しくメモリ確保して前の配列は解放されなかったり解放タイミングいつか分からなかったりっていう今時の言語を微妙にした感じの動きをしている感じ。

※忙しいときは土日仕事とか業界結構あるので気をつけよう！ 確認したいことのほとんどは れいさんがやっていて、社長にもPRG系使い勝手微妙なのは伝わったっぽいので、今後のプチコンアップデートに期待。 命令と配列のアクセスの遅さは初期型3DSとNew3DSでどこまで違うのかもちょっと気になるけど、New3DSはDQ11までおあずけかなぁ。

※時前→自前 エディタコード自体は DEF MAINあたりで全部くくっちゃえば名前空間の汚染もしなさそうだし。 コンソール画面だけしか使わなければ編集コード側でBGやSPRITEいじってても影響なさそうだし。 あれ、CHKVAR で変数名存在チェックはできるけど、変数の名前を文字列で渡して変数の値を取得ってなさげ？(VAR でできると思ったけどリファレンスになさそう？) BACKTRACEがDIRECTモード専用なので使おうとするならKEYでファンクションキー登録してなんやかんやが必要そう。 と、実機をさわらずにリファレンスを見ながら思いつくままにいろいろ書いてみた。

エディタの起動、編集SLOT、コード実行、コード実行後のエディタへの戻り　がちゃんとできれば、あとはBASICコード上で文字列解析して好きなようにエディタが実装出来る感じかなーと。 命令テーブル作って一致するのを命令用の色で表示できるし、 ラベルも行番号とかタグジャンプできるし、 変数代入をみかけたら後ろのコメントを変数名の説明として別の変数使用場所で表示もできるし、 命令もわざわざ手打ちしなくても命令リストから選ぶだけでできそうだし、 キーボードも時前で全部作れちゃうし。

「プチコン上で動くプチコンの高性能エディタ」について、ちゃんと作るとすると、起動が一番悩みどころなのかなーと思ったので、何か良いアイデアとか、使い勝手とかを聞いてみたいなーと。 ちゃんと起動できればPRGEDIT/PRGGET$系でなんとでもなりそうだし。 ※ほんとはちゃんといろいろさわってから立てた方が良さそうだったけど、ちょっと３号動かした結果とリファレンス一覧見てなので、実際やってみたらできるかもしれない？ 本文じゃ長くて書けなかったので、以後コメントに。

・エディタ.BASをSLOT 0に呼び出して実行→SLOT 1を対象にエディタ操作 エディタ上から実行しようとして USE 1 して実行すると SLOT1 は PRGEDITできなさそう(USE OFFみたいなの無さそう) エディタ上から編集コードを実行したら、STARTボタン/ENDでぬけて、またRUNすればよさそうかも？(STARTボタンで停止→STARTボタンでエディタ実行→エディタ上でRUN機能呼び出し) 編集するコードのメインループにエディタDEFを呼び出せばデバッグモードでassert やウォッチリストみないこともできそう

とりあえず思いつく限りの手法とメリットデメリットを。 ・スマイルツールに登録して起動 使う側は楽、スマイルツールボタン誤タッチも回避できる。 スマイルツール呼び出し前のSLOTをちゃんと操作できるかが課題。 STARTで止められたらツール呼び出し前に戻るのでメモリデータが飛ぶかも？ スマイルツール側で編集したSLOTにコードが残るなら、スマイルツールボタンがエディタ代わりに使えそう？

画像病が速度とか配列アクセス速度とかフリーメモリが全体の空きじゃない(配列用とか文字列用途かいろいろ上限あるイメージ)とか、プチコンは結構癖あるっぽいので、たぶんGSAVE/GLOADで一括読み込みしたほうがよさそうかもです。 みなつさんが前に 512x512未満 GLOADが60fpsでも動作するって試してた感じなので、そのくらい GRP一括アクセス系は早いイメージです。

それだと塗りつぶしのundoコマンドが間違ってる感じかも。 たぶんGPAINTだけだと思うから、自作GPAINT＋影響範囲しらべる（塗りつぶし場所全部覚える）を実装する必要あると思うけど、 あまりにも変更点多くて大変な条件なら影響範囲分の前画像覚えた方が早そうかも。 SBGEDとかsys/系の場合は改造してもらう前提もありそうだし、動くけど特定の場合はちょっとおかしいかも、ってのが残ってそうな感じしそうです。 結局は変更差分さえあればどのバージョンにでも戻せるっていうバージョン管理システム(gitとかsvnとかcvsとかrcsとか)と同じ理屈なので、差分ちゃんと求めるのをどうするかって感じですね。