簡易な文字数削減方法は無いでしょうか。 ・現在の状況 文字コード２５６未満の文字が３つ以上連続するとき１文字に２文字を詰め込んで、文字数を減らす。パック・アンパック処理と文字列の送受信を平行して実行する。旧３ＤＳ側で処理が遅いためDEFを外して、スパゲティ化してなんとかそれなりに処理出来るようになりました。 しかし、プログラムによっては、２割弱の削減しか出来ません。また、連続する同一文字列を圧縮する方法を試しましたが、１割弱の削減にとどまり、効果が薄いと感じています。旧３ＤＳだと合計時間が余計にかかってしまいます。 プチコンの命令や関数名を圧縮することも考えていますが、まだ試していません。

よく知りませんがハフマン符号使うとかどうでしょう

送信前に圧縮、受信後に解凍ではダメなんでしょうか。 256文字に限定せずファイル全体を圧縮すればもっと効率が良くなるのでは。

文字列の圧縮なら、使用文字のリスト化が比較的簡単だと思います。 使われている全ての文字をリスト化して連番を付けます。 そのリスト数によって、1文字を何ビットで送るかを決めます。 普通に送ると「16ビット*文字数」の総データが必要だったのが、 128種類以内だと、ヘッダ＋7ビット*文字数 256種類以内だと、ヘッダ＋8ビット*文字数 で送信できます。 復元は逆に、ヘッダのリストを展開して、本体データを指定ビットずつ分解してリストと照らし合わせ、文字に直していきます。 漢字辞書ファイルみたいに文字種類が多い場合は、かえってサイズが増えますけどね・・・

コメントありがとうございます。 ZEXさん 最適なビット長を決めるアルゴリズムのイメージが浮かびません。今の私には、荷が重いようです。 あきとさん ファイル圧縮の場合はその方が良いと思いますが、全体にかかる時間を考えるとかえって長くなるかもと考え、送受信の合間に行う処理を選択しました。この選択に問題があるのかもしれませんが^^: 現状の送受信時間は、１万文字でだいたい２秒かかります。 みむさん そうなんです。説明やコメント等で漢字を使っているので、文字種が増えてしまうんです。

秒速５０００文字？？？

はい、１２８文字＊６０フレーム＊０．６６ぐらいです。

UTF-8に変換して詰め込むだけでも多少はましになる気がします。 それ以上の圧縮となると、ビット単位で詰め込まないと無理そうですが、旧3DSだと処理速度が厳しそうです。 手元にある圧縮ルーチンで一番速いLZWでEX8TECHDEMO(47,611文字)の圧縮に5秒強、展開に4秒弱(旧3DS)。圧縮結果が13,120文字なので、1万文字2秒だとかえって遅くなります。 圧縮しつつ送信すれば、圧縮と展開を2つの3DSで並行して行えるので、多少はましかもしれませんが。

なるほど・・・私、以前GRP転送で色々してたんですが、無圧縮で3:52が最速でした。 　512x512x2バイト/232秒＝2260バイト/秒 GSAVE＞文字列化＞MPSEND＞数値化＞GLOADしてるので、こんなもんかなと思ってたんですが、秒速5000出たら倍速ですねぇ。

てらこやさん プログラム限定ですが、コメントなど文字コードの大きなものが偏在する場合は、パックするのと大差は無いようです。 ＬＺＷの圧縮率は高いのですね。今までファイルの圧縮は、考えていませんでしたが、これからは、使ってみようかと思います。 みむさん プチコンは、１フレームに１回送信しているようですが、相手に届くまで最短３フレーム（往復６フレーム）かかっているらしいことと、送信バッファが４面であることから、今のところ０．６６ぐらいが限界になっています。 。もっと良い方法があるかもしれませんが･･･

思いつきですが、複数のファイルを送る場合には、ＬＺＷを使った方が早くなるような気がしてきました。

同じ文字をまとめる前にブロックソート(同じ文字をできるだけ並べてもとに戻せる)? かえって遅くなるか。 圧縮は難しいですよね。プチコンはじめからずっと考えててやっと、数値配列を同じやつが二つ続く圧縮(ランレングス)をやったぐらいです。

ヨッシーさん ソートのイメージはよく分かりません^^; わたしは、スペースを多用するので、ランレングスをしてみましたが、４つ以上続かないと効果が無いので、効果は１割弱になりました。 （１割もかもしれません）

速度はわかりませんが、スペースを大体1箇所に集めることはできると思います。 ただ、ブロックソートは普通 ブロックソートと会わせてさらに別のやつをやって、ハフマン符号化とかをするらしいです。

ハフマン符号化は、文字コードを、「たくさんある文字に短いビット長のコードを割り当てる可変長のコード」にして、文字列を一列に並べれば、文字列全体の長さが短くなる場合があると言うことらしいです。（詳しいことはよく分かりません。）文字毎に割り当てる最適なビット長を決めるのが「きも」らしいですが、そのアルゴリズムがわかりません^^;

へー

圧縮と送信は並列に動作可能で、受信と伸長も同時にできるので、それぞれほぼ同時にできるようなのが早いよね。 送信フレーム辺りのバイト数を丁度フレーム時間で圧縮できるようなもので圧縮効率の良いもの。 昔圧縮ライブラリ作ったときの感じだと、 名称 速度 圧縮率 lzss 50kB/s 40% lzw 10kB/s 30% ハフマン 20kB/s 80% くらいだった。(new3ds 生で5kB/s程度の転送速度ならどれでも十分間に合いそうなんで圧縮と並列動作させたらいいんじゃないかな 旧3DSを考えるとハフマンはきついとおもうが。

れいさん フレーム時間ぴったりだと２５％くらい実効速度が低下するようです。 （VSYNCを入れた場合の実効速度低下です。） VSYNCなしで、送受信ログを取ってMAINCNTの値を見ると、同一フレーム内に２回送受信する場合が、見受けられます。 （推測ですが、送受信側のフレーム位相差が原因と思われます。）

ん？ 画面更新のフレームじゃなくて wifi送信のフレームね。 時計も音声入出力もWifiもカメラもCPUも、基本は同期しては動いてないのでジッタあるのは普通。

こ

LZSS+UTF-8化を速度重視で調整しましたが、旧3DSで圧縮3.73秒、展開0.22秒が自分の限界でした。サイズは47,611→16,114文字で、UTF-8化だけして送った方が速いという結果でした。 8ビット文字をパックするだけでサイズがほぼ半分になってしまうので、そこから圧縮して3～4割減らしても圧縮時間で相殺される感じです。 れいさんの言うように、圧縮と送信を並行して行うしか手はなさそうです。

圧縮・解凍に時間かかる時間が増えると、いきなり送信時間が増えるタイミングがあるので、旧３ＤＳを考慮するときは、圧縮方式に妥協した方が良い場合もある気がします。（方式のネゴシエーションをすれば解決すると思いますが、New同士の場合は、試験環境がありません^^:） 「D37NN364」パック方式しか対応できず、無駄な処理もあり、複数ファイル対応など、改善する必要がある版です。（インターバルタイマーに入れていたものを、改善したものです。）

LZSS使うならUTF-8化する意味ない。 1文字16bitのまま圧縮したほうが早い。 どうせ空のビットは圧縮で消える。 圧縮にかかる時間が予想できないってのはちょっと問題で、 任意バイト列の場合圧縮しないより遅くなってしまう可能性もあるけど 文字列ならそれはないので 平均速度適当に見繕ってそれに合わせておけばいいのでは。

言葉をいい加減に使用したこちらのミスです。すみません。 LZSSと書いてしまいましたが、実際には適当な文字をタグにして後ろに長さと位置を続けるだけのものでした。UTF-8化しているのはそのためです。 あと、圧縮速度は、あくまで自分の限界ですので、旧3DSでの送信に間に合うように作れる可能性はあるでしょう。

[C3NNV3Z4] 空き時間の使用と送信時間の関係を調べて見ました。新旧3DSの1/10フレーム単位にしたつもりですが、間違っているかもしれません。

私の送受信プログラムが遅いせいかもしれませんが、半分以上使うと速度低下が大きくなるように見えます。片方だけを変化させる計測をしていないので、参考にならないデータかもしれません。 プロジェクトの内容 CMD_LIST321:CMD_TBLCVのテストデータ CMD_TBLCV:命令を番号にして短縮＋ランレングス 　実行速度が遅いため、このままでは使えそうにありません。 TEXT_SEND2:送達確認時の、文字数チェックをやめました。 TEXT_SEND4NEW:New3DS用時間計測テスト用 TEXT_SEND4OLD:旧3DS用時間計測テスト用

他の圧縮方法は、公開されているプログラムで勉強する予定です。

コータさん北海道に住んでますか？

ミーバースでは、個人情報を聞いてはいけませんよ。 北海道には行ったことがありません。

パックとランレングスを一緒にしたら、新３ＤＳ－＞旧３ＤＳは少し早くなったが、旧３ＤＳ－＞新３ＤＳが遅くなってしまいました。 圧縮・伸張に使える空き時間は思ったより短いのかもしれません。

既出とは思いますが、プチコンでユーザが垂直同期間に使える時間は、思っていたよりばらつきが大きかったです。 [N3K5K453] TST_AVL_TM 空き時間分布 　MAINCNTが変わるまでの間に何回＋１したかを数え、約５秒毎に度数分布を棒グラフで表示。 TEXT_SEND2.2 テキストファイル送受信 　１）処理選択をタッチで出来るようにしました。 　２）テキストファイラー対応：送信ファイルを複数選択後に実行すると送信になり、送信ファイル選択せずに実行すると受信になります。受信プロジェクトは、TEXT_SEND2.2のあるプロジェクトになります。受信後移動してください。受信時は、ゴミ箱機能は働きません。 　３）グラフィックページの転送機能を付けましたが、まだ、試験していません。

あまりうまくいきませんでした。いつか再挑戦しようと思います。 （その前に誰か、良いものを出してくれて、それを使うことになりそうな気がします^^;） [JRVXVWKV] TEXT_SEND1.0 テキストファイル送受信 ・変更点 １）グラフィックページの送受信で、ランレングスを送受信と平行して実行するようにし、ＵＩを少し改善しました。 ２）無線が混雑しているときのために、圧縮にDEFLATEを使う場合を追加しました。（圧縮・伸張には、てらこやさんのプログラムをそのまま使っています。） ３）不要な処理をなるべく削除しました。

同期をやめて可能な限り圧縮にリソースを割いてみましたが、自分の実力だと旧3DSで1秒縮めるのが精一杯な感じです。 UTF-8化だけで5.2秒、そこから圧縮して4.2秒強でした。 テストプログラムは、公開キー【PREXVW8V】のMPSEND_LZ77になります。

旧３ＤＳを対象として考えると、並列動作させようとしたときに、使える空き時間を超えてしまうため、圧縮率ほどの効果が期待できないのではないかと思いました。 無線がふくそうしているときは、効果を発揮できますが、その場合は圧縮率の高いDEFLATEの方が良いのでは無いかと考え使わせていただきました。 なお、データファイルの転送は、今のところ、私が必要性を感じていないのと、倍精度実数のバイナリ形式変換がうまくいっていないため、盛り込んでいません。 （テキスト形式データは、サイズの大きくなる問題がありますが、試験が楽なので、テキスト形式を採用してしまいます^^;）