圧縮展開ライブラリLZSSLIBバグありだったので更新 Ver.1.0.1。【R584E83E】

安定の薔薇を確認させていただきました！ 保存した薔薇と　圧縮された薔薇を比べると約1/7以上ファイルが小さくなっているであります！　いつものことながら凄いであります！　更新お疲れ様であります！

PMODEM121でPCから3DSにUTF8テキストを転送しています。 大変有用なツールをありがとうございます。 転送していると、ときどき文字化けが起きます。プロトコルは1200bps Send w/ARQ なんですが。 これって信頼性のあるプロトコルではないのでしょうか??

え。まじで？ CRCで確認してるから文字化けしてたら再送するはずなんだけど。 CRC潜り抜けちゃう場合も理論上はあるけど、ごくごくレアケースのはず。時々って頻度ではないはず。 バグかなぁ あ、バイナリファイルなら拡張子".DAT"つけて。 それ以外で送るとテキスト扱いになって、プチコン側が勝手に0x0Dと0x0A変換しちゃうので。

本来置きにくいはずなんですね。うーん・・・ 文字化けするのは別件で投稿した人工ぷちのう3号のデータなんですけど、だいたい決まった場所で起きるみたいです。元データで改行は最後に一つだけ入っています。 プログラムエディタにloadしてみるとデータの後ろに空白的な何かが大量に入っているのも不思議です。

決まった場所で起きるならバグっぽいねぇ PC側のファイルの文字コードはUTF-8にしてある？

全然関係ないけどみき氏は結構な頻度で髪型かえてるよね おしゃれか

元データは二分木なんで、windowsのNTFSでディレクトリツリーそのもので作りました。それをたどってファイル名をそのままデータ化しています。文字コード詳しくないけど、シフトjisじゃないみたいなんで、たぶんutf8なんじゃないかなあと・・・ ついでに質問ですがディレクトリ深さかパス全体の長さが制限あるみたいで、あまり深いとこはディレクトリ作れなくなって困ってます。なにかいいツリーエディタご存知ありませんか? 髪型はにぎやかトレインの主人公のつもりだったけどわかりにくいっすねww

これはひとりごとなんですけど、画像以外も圧縮伸長できたらいいなあと・・・

おおお。言われてみれば似てるわ。かわいいね。 NTFSパスの長さは普通は250文字。工夫したら30000程度。 どんなソフトでパス辿ってるのかわからんと文字コードわからないが、特定の文字で化けてるわけではなさそう。 おかしいなぁ。文字コード変換で間違ってんのかな ツリーエディタなんて使ったことないけど 二分木つくるならテキストエディタで作るかな PerlかRubyあたりで適当に構造つくって。

え。できるよ？ って思ってみてみたらPC側は機能削ったのしか上げてなかったか 実数配列の扱いに困ってて説明面倒だから削ったんだったw プチコン側のLZSSLIBは画像・文字列・整数配列の圧縮伸長できるようになってる。 PC側に文字列と整数配列の圧縮伸長が欲しいということでしょ？

cygwinのperlで use Encode qw/encode decode/; #おまじない @v=<*>; #ファイルリスト取得 $qa[i] = decode("utf8",$v[0]); # utf8->utf16 的なコードでやってます。これみたら元データはutf16ってことかな?????? 最初excelでつくろうとしたけど、サブツリーの付け替えができるのはIEだけって思ったので。

PCでテキストファイルをImageConverter.exeに食わせて、PetitModem.exeで3DSに送って、3DSのナニカに食わせるとテキストファイル復元できるというイメージだったのですが、最初のステップでImageConverter.exeがクラッシュしたのでした。

それじゃわからんw @vにUTF-8文字列がバイト列で入っているということを仮定しているとしか。 ファイルリストに何を食わせてるのかと出力どうしてるのかを示してくれ

見逃してました。さーせん。 今から出かけるのでまたあとで報告します!!

ファイルをnotepad.exeで開くと最初は ("とくていのひとかキャラクターですか"("ボカロですか とあって、16進ダンプしてみると 00000000 28 22 e3 81 a8 e3 81 8f e3 81 a6 e3 81 84 e3 81 (".............. 00000010 ae e3 81 b2 e3 81 a8 e3 81 8b e3 82 ad e3 83 a3 ................ 00000020 e3 83 a9 e3 82 af e3 82 bf e3 83 bc e3 81 a7 e3 ................ 00000030 81 99 e3 81 8b 22 28 22 e3 83 9c e3 82 ab e3 83 ....."("........ となってます。

PetiModem.exe で文字コード変換するのですか? 転送が信頼性あるなら、その前に化けてる可能性ありますよね? ascii なら問題なさげなので、pc側でutf-16にして、hexで送ってみます。サイズ倍になるのが悲しい。base64がほしい。

上の方法で転送成功しました!! ありがとうございました!!

PC側でUTF-8、拡張子TXT改行CRにしてPetitModemに送るとプチコン側でUTF16、改行CRで保存されるはずなんだけどなぁ まぁ今度使う時見直すよ。 ついでにテキスト圧縮もかんがえとく

スマホアプリにする予定はありますか？

ない。

ありがたく使わせてもらっています。 テキスト転送で文字化けする件ですが、調べてみました。多バイト文字コードが2つのパケットに分割格納される場合に発生するようです。 添付画像のように全パケットの内容を連結してからコード変換すると、とりあえず回避できます。 ただこれだとメモリ効率が悪いので、ちゃんと直すならパケット跨がりをチェックしながら、必要に応じて連結して、コード変換する感じでしょうか。

いわさきさん、情報ありがとうございます。 あとで試してみます。 base64作ったんだけど、いたづらになりにけり・・・か? それはそれでいいや。 あと、ツリーエディタはMSのxmlnotepadがよさそうな気もしてきました。たまにクラッシュするのと、エレメント?の先頭に数字使えないという問題がありますが。あとXMLのparser書きたくない。

いわさきさんの方法で文字化け解消しました!! ありがとうございます!!

今度治すわ

ありがとうございます！かなりお世話になっているので対応してくれると嬉しいです。 ついでですが、いくつか提案させてください。 プチコン側の受信について、拡張子によってリソース種別を決定していますが、デフォルトをTXTではなくDATにしませんか？ PC側でテキストファイルは拡張子TXTにする場合がほとんどですが、バイナリファイルの拡張子は非常に多いので。 自分はPC側からPNGやZIPを送りたいときは、PC側で拡張子をDATに変更してしのいでいました。

プチコン側でプログラムの受信と保存ができると、かなり開発が楽になります。 この場合、拡張子はリソース種別に合わせてPRGというのはいかがでしょうか？ 現在開発中のプチコン用ZIPでは拡張子PRGのファイルをPGEDIT経由でプログラムとして保存します。 こんな感じです。 PRGEDIT 3 PRGDEL -1 PRGSET V$ PRGDEL SAVE"PRG3:"+OFN$

これは自分の勘違いかもしれませんが、一応書いてみます。 再送処理についてですが、送信側と受信側でタイミングが少しずれた場合に、同じパケットの再送が繰り返され転送速度がかなり落ち込むことが頻発します(数バイト/秒)。送信側が再送要求を取りこぼしているような感じがします。 そこで、以下のように再送処理の効率化を提案させてください。簡単に言うと「ひとの話は最後まで聞こう」です。 CRC不一致の場合、そのパケット番号を再送要求リストに追加して受信処理を継続。 受信処理が終わったら、再送要求リストが空になるまで、パケット単位に再送要求して、成功したら再送要求リストから削除。

1. 俺もそう思ったので開発中の次の版は既にデフォバイナリになってるw TXTとPRGだけテキスト扱いにした。 2. もともとプチコンにプログラムソースを送るためのものなんでそのまま送って実行できるはず。上のバグを除けば。 3. 俺の経験では、同じところで何回も引っかかっている場合は「ダメパターンのデータ」を送っているんだろうと思われる。音量変えたり環境変えてくれ。 提案の方法はステート管理が難しくなるし、ダメなときに再送リストが全パケになって無駄。 今は「再送要求」と「送信要求」を区別せず、とにかく持っていないパケを数個送るように作ってある。ロス時間は十分小さいはず。 稀にどうにもうまくいかなくなる場合がある。最初のパケしか読めなかったり。 プチコン再起動で治るので怪しいときは再起動で。

いろいろアドバイス等ありがとうございます。プチコンは始めたばっかりなので、勉強になります。 1. これは嬉しいです！ 2. 知らなかった。。。プログラムはSAVE "PRG*:"でしか保存できないと思ってました。テキスト扱いでOKなんですね。 3. なるほど、さすが作者様です。ケーブル接続ですが確かにPC側の音量で転送速度が左右されるようです。ベストな条件を詰めてみます。

いやアドバイスもらったのはおれのほうじゃね？どうみても。 ケーブル接続でもだめなときあるのか。 要求と送信がずれるときはたしかにあったんだけど、一回だけで再現しないんだよね。 なんかおかしいところはあると思うんだが。 リアルモデムはよくできてるわ

いえいえ、とんでもないです。作者様直々に教えてもらえるのは、非常に心強いです。 ケーブルといってもおおげさなものじゃないですよ。 4極分岐ケーブル(メス:SSA ServiceのST35-SM35F)を3DSに挿して、ステレオケーブル２本でPCのライン入力とライン出力に接続しています。 一応半田ごてつかって自作ケーブルも作りましたけど、上記の無加工のケーブルでもいけることが分かったので、そのまま使っています。 イヤフォンマイクと比べて環境の影響を受けにくく安定しているのでおすすめです。

PC側の音量を調整してちょっと実験してみました。音量が高ければよい、というわけじゃないようですね。 PC側から9KBのバイナリファイルを1200bps、Send Simplexで送る条件です。 音量 欠落パケット数 100% ∞(ファイル名すら取得できず) 75% 同上 50% 8 45% 1 44% 0 40% 0 30% 0 23% 0 22% ∞(ファイル名すら取得できず) 20% 同上 PCからの転送で欠落パケット無しで送れる条件があることが発見できて、大きな収穫でした。いままでは適当に50%でやってて歯抜けになるのを前提にARQで送っていました。 今回の実験をふまえて、これからはPCの音量レベルを35%ぐらいにしたいと思います。

ああ、ケーブルなのに音量おおきかったのか。 FSKなんで音割れにはかなり強いんだけど、ケーブル接続で音量大きいと入力レベルが違いすぎてエコーみたいな歪みが出るから無理だね 俺はケーブルの時は10%以下だな ところで、「作者様」はやめようよ 日本語としても変だし、自分のために遊びで作ってるだけだし 特にこのゲームはプログラム作るゲームなんだから、全員作者様。お互いに作者様なんて呼びあってたら滑稽だよ。

エコーといえば、3DSの音声出力をPCのライン入力にして録音デバイスにしてるんですが、3DSの音声がPC側で再生されて、PCのライン出力経由で3DSのマイク入力に戻ってきますよね。 このライン入力のレベルが高いと、よくない影響が出る気がするので、暇を見つけて検証してみます。 おかげさまで開発中のZIPアーカイバがBETA版くらいの形になりました。RBKXNNAEです。よかったら使ってみてご指摘頂けたら嬉しいです。 「作者様」ですが、了解しました。以後、れいさんにします。 いやー、オープンソースの生活が永いもんでつい。。。 でもお世話になってるプログラムの作者に対する感謝の念は常に持ち続けいたいと思います！

Playbackな。 Win7以降は標準でonoff設定できると思うで。 でもいまんとこpetitmodemは送信受信で周波数変えてるから戻ってもそんなに問題にならないはず。 同一周波数で通信するにはエコーキャンセラいれないといけないんだけど、速度的にちょい厳しいかな。 つか、オプソならより作者様は変だろ オープンなんだから、皆が作者でいいわけだし。 対等なことが正しい社会では対等なら言葉づかいをするのが礼儀だろ それと、感謝してるかどうかは別。 うわべだけ持ち上げてりゃ礼儀にかなってると勘違いしてる奴多いがね。

自分の作ってるゲームのファイルサイズが 大きくなってきたので使わせて頂こうと思いまして。 既に作ってあるGRPイメージを圧縮したいのですが LOAD"GRP0:AAA.GRP",FALSE SAVELZIMAGE "AAA.DAT",G%,511,511,TRUE という具合にやってみたが、 Subscript out of range がでちゃいますねぇ・・。 引数の説明も拝見したので、有ってると思うのですが 以上、報告です

DIM G%[0] LOAD"GRP0:AAA.GRP",FALSE GSAVE 0,0,0,512,512,G%,1 SAVELZIMAGE "AAA.DAT",G%,512,512,TRUE こんな感じで

ああなるほど、GSAVEですか。 試したところうまくいきました。 524,316バイトあるGRPデータが70,972バイトまで減りました。 これで1プロジェクトに収めれそうです。 ありがとうございます。