2次元数値配列を使えば画像の一部を保存することができますが、 この場合SAVE"GRP0:～の時とはアイコンが違ってしまうのが寂しい。 4M制限あるし、GRPの部分保存対応してほしい…

一旦GRPFに読み込んでから保存すると、上1/4のサイズ(512x128)の画像が作れますよ( ´ ▽ ` )ﾉ 読み込むとグラフィックページの上1/4だけ上書きされるので、使うときは、読み込んで下にGCOPY、を繰り返す必要があるかもしれませんけれど、サイズ的には無駄なく使えると思います♪( ´▽｀)

宣伝のようで恐縮ですが、まもなく公開予定のお絵描きツール最新版に搭載している、画像を部分保存する関数です。 ご投稿の方法だと、全画面セーブと比べて、ピクセル数あたりのファイルサイズが倍になってしまいますが、その問題を解消しています。 アイコンは変わりませんけどね…

上記で保存したファイルを読み込んで表示させる関数がこちら。 打ち込むのが大変でしたら、お絵描きツールの最新版が公開されたら、関数だけコピーしてください^^;

返信してくださったお二人のお絵かきツール，いつも楽しく利用させて頂いております:) >スーさん フォント用リソースという手がありましたねー． アイコンにこだわるなら現状この方法しかなさそうです． >なおさん 丁寧にありがとうございます．正直これぐらいのフォーマットを公式にして欲しかった……． 形式判定用に4byteくらいのIDと，対応してることを伝えやすくするための名前があると良いなと思います． (ちょっと言い辛い)PCからの転送ツールを作っているのですが，こちらのフォーマットでも出力できるようにしたいです．

なるほど。確かにIDをつけた方が色々便利で将来性も拡がりますねー。 では、(少々大げさですが…)下記の形で考えてみたいと思います。 ・このフォーマットを「PGRP形式」(Partial-GRP)と名付ける ・ファイルの先頭は「PGRP」の4文字のASCIIコードを繋げた32bitのデータ(&H50475250)とする ・あとは上記ソースの通り プチコンのファイル構造が不明なので、用語として不正確かも知れませんがご容赦下さい。 ご意見ございましたらよろしくお願いします。m(__)m

ファイルの先頭のIDはIDというよりバージョンにして 拡張子で判定のほうが伝統的でわかりやすいような。 当然拡張子は3文字がいいので「PGRP」だと長すぎ。 「GRP」は使えないし「PGP」は間違えるので「PGR」形式を推します！

ご意見ありがとうございます。 (myu314さんすみません、アレでしたら新しいスレを立てます。) 私としては、拡張子をつける習慣がプチコンユーザにない気がするので、拡張子ありきで判定するのはちと気が引けます。 エラーキャッチができないプチコンでは、確かにエラー回避のひとつの手なんですがね… 名前は3文字の方がわかりやすいし、PGRがいいですかね。 ファイル名で管理したい人は.PGRをつけてもらう方向で。必須にするかどうかは実装依存。 ヘッダにバージョン番号を入れるかどうかは悩んでいたので、空いた 1文字はバージョン番号として、とりあえず1を入れる形(つまり「PGR1」で始まるファイル)で考えてみたいです。

公式ツールはヘッダとなる文字列（４文字）の後にバージョン番号を別で入れてましたよ。例えばマップなら、MAP:の４文字で次の値がバージョン番号だったかな？ 僕も拡張子はプチコン的には一般的じゃないのかなぁ、という気がしています。とくにファイル名の長さの最大が短いので、拡張子に４文字（.も含めて）取られるのは痛いなぁ…と。 まあファイル名に含めると見た目でわかるのは大きなメリットではあるんで悩ましいところですけどねー…。

誰か画像フォーマット作ってくれないかなー長いものに巻かれたいなーと思っていたので，この流れは非常に嬉しい今日このごろです:) 個人的には拡張子付けるほうが好みなんですが，みなさんおっしゃってる通り拡張子があまり使われてないのと，公式のリネームだと何故かアンダースコア以外の記号が入力できないんですよね…． そんなわけで拡張子をつけることを推奨しておいて，あとは実装にお任せに1票．拡張子さえ決まっていれば上手くいくのでは． ただ拡張子PGRはPRGと似てるなーというところだけ引っかかってます．細かくてすみません…気にし過ぎかなとも思ってます． あとIDのとこバージョン入れてしまうのもそれが良いと思いました．4byteに納めれば判定も楽ですしね．

公式になるべく近いほうがいいですよねぇ じゃあこんなのは？ 汎用ヘッダーとして4バイト単位で [0] 「リソース名」っぽい3文字をASCIIで上位から。「PGR:」なら&H5047523A [1] バージョンを32bitで。 [2-] リソースのデータ PGRの場合は [2] 「(width<<16) OR height」を。 [3-] 2ピクセル毎に32bitにまとめて左上から行優先で右下に。 拡張子はPC転送の時に欲しいだけなので、欲しい場合はPC側のソフトで対応。 プチコン側では基本拡張子無し。

実はあまりスマイルツールを使いこなしていないので、MAP以外も含めて自分でも確認してみますね。 統一性があるようなら、準拠する方針で。 (他に配列をセーブするツールあったかな…情報求む^^;) PGRがPRGと紛らわしいのは確かですねえ。実際打ち間違えました。 というわけで、「PTG」でどうかな…

帰宅したので確認してみました。 ・MAP（SAVE）→[0]="MAP:"、[1]=1 ・MAP（BGSCREEN SAVE）→BGSAVEの生データっぽい ・ANIM（SAVE SPDEF）→[0]="DEF:"、[1]=1 ・WAVE→生データっぽい と、ヘッダがあるものについては統一されているようでした。(2コだけですが） ということで、基本的にこれに準拠する形（れいさん案）でいこうかと思います。 名前（形式名/推奨拡張子/ヘッダ上のリソース名っぽいの）については、他に紛らわしいものがなければ、「PTG」（ParTial Grp）で行こうかなと。 3月初旬くらいに、お絵描きツールの最新版と同時に、ライブラリを公開してみますね。それまでの間、異論があれば検討して反映させたいと思います。

おぉ 汎用フォーマットできた感じですね あとは布教か… メジャーなツールで採用されるといいですねぇ

このスレにちょこちょこ共感を頂いているスーさんが採用してくれそうな気がする…||ω・）ﾁﾗｯ （強要しているわけではありませんすみません） あと私ももちろん。 ロッドさんは興味なさそうだなーこういうのは。

とりあえず読み書きルーチン作ったので置いておきます． インターフェイスはなおさんのやつに揃えてみました． 公開キー: 54D3W39J それなりに高速化してNew3DS/512x512で読み書きともに40F弱くらい．旧3DSだと2秒くらいになるのかな(試して無いけど概ね3倍くらいになると思う) 512x512だとちょっと遅いですけど，サイズ半分になるしユーザー側でできるフォーマットとしては丁度いいところだと思います． GSAVE/GLOADのフォーマットを最初からこれくらいにしておいて欲しかったなぁ．

ありがとうございます！ 今こちらでもライブラリ兼デモを作ってまして、（参考公開キー：K2DPXAD）、高速化して頂いたのであれば、マージして正式公開できるように考えてみたいと思います。 それと、（こういう使い方をすると怒られるかもですが、）ほしけんさんのプチコン3号まとめwikiの投稿プログラムコーナーに、上記のライブラリと仕様のドラフトページを置かせてもらいました。 ドラフトなので、わざと古い日付にしています。2000年2月の欄をご参照頂けますでしょうか。

まとめwiki読みましたー．丁寧にまとめられていて素晴らしいです． ライブラリですがPTGDECODEあるならPTGENCODEあってもよいかなーと．キャッシュとかの保存に使えそうです． あと，なおさんの丁寧なサンプル見たあとに自分のソース見たら死ぬほど読みにくくて，なんというかごめんなさい(笑; コメント全く入れてないので一応簡単に説明を． ・ループ中のPUSHは重そうなので，先に配列確保 ・4ピクセル毎に処理してループ中のIF分除去，端数は最後に場合分けして処理 と，基本的にループ中の処理を追い出しただけです． ちなみに8ピクセル毎でも良かったんですが，数フレームしか変わらない上にリストが更に長ったらしくなるので止めました．

そうですねー。PTGENCODE(myu314さん版でのGRP2PTG？すみませんまだちゃんと読めてません^^;)もつけたいと思います。 (デモるのが難しいので、デモからは外そうかな。) ただ、ライブラリ内の関数に依存関係があると、必要な機能だけを切り出して使おうと考えたユーザが、どこまでを切り出せばいいかわからなくなってしまうリスクがあります。 ので、例えばPTGSAVEがPTGENCODEを呼ぶ、という構造は(ソースの二重書きになりますが、敢えて)やめようと思っています。

マージしてみました！（公開キー：2BK438QV） いうか、ちょっとI/Fを変えたくらいで、ロジックはそのままmyu314さんのコードのままですが。 もし変なとこがあったらご指摘下さい。 一旦私のお絵描きツールに組み込んだ上で実地テストして、正式公開とさせて頂きますね。 （端数の場合分けの網羅テストがまだできてない…） DEFでの配列の戻し方とか正直よくわかってなかったので、いろいろ勉強になりました。 大変ありがとうございました。m(__)m

すみません、ソース内のコメントに誤記があったので再UPしました。m(__)m 公開キー：K4DX42D

マージありがとうございました！ これで後は普及ですね:) 広まって公式で対応してくれたらいいのになぁ…

アップロード容量が制限されているのに画像でかなり容量が無くなってしまいますし、SAVE"GRP:HOGE",A、とか、SAVE"GRP0:HOGE",256,0,512,128、みたいなことが出来ると良いのですけれど(´=ω=｀) 部分SAVEが出来るようになったらLOAD時の位置指定もセットで欲しいですね。 私のエディタでもPTG形式はサポートできたら良いな、って思うのですけれど、操作の導線が悩みどころです(´ω｀;)

ツールからの導線は難しいとこですね。 セーブについては範囲指定機能さえあればイケると思いますが、ロードが。 参考までに私のツールでは、PTGファイルを読み込むと、コピー＆ペースト用の領域に入るようにして、ペースト機能で貼り付ける形にしています。（というか今まさに作ってます…）

実のところ、私の最初の思惑では、部分セーブ機能はあくまでセーブだけにして、ツールからのロードには対応しないつもりでした。 自作プログラムから部分ファイルを使いたい人は、ライブラリを用意するから使ってね、という形で。 そういう割り切りでも別にいいんじゃないかなーと思います。