推測なので間違っていたら、すみません。 可能性１）ユーザ定義命令SPCOLCでスプライトを解放している。 可能性２）変数Hがグローバル変数で、ユーザ定義命令SPCOLCで書き換えている。 ユーザ定義命令SPCOLCで何をしているかと変数Hのスコープがグローバルなのかローカルなのかが気になります。

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

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

見かけは関数、中身は定数、その名は円周率Π。

トピックが閉じていたのでこちらにコメントします。 どうしてもやる必要があるのであれば、こんな方法もあります。参照値の代入を使う方法なので、メインルーチン以外で使うときは、参照値引き継ぎの考慮が必要です。 ・SLOT0(H0) DIM H[0] EXEC "PRG1:H1" H=HOGE("H") FOR I=0 TO 9:? H[I],:NEXT:? ・SLOT1(H1) DIM H[10] FOR I=0 TO 9:H[I]=I:NEXT COMMON DEF HOGE(A$) RETURN VAR(A$) END

Ｈ０に ＤＩＭ　Ｈ［５１２］ がないために、７行目でエラーになっているのではないでしょうか。 なお、SLOTが違うと変数の名前が同じでも違う変数として扱われるようです。

2015/12/12 18:00 要望の訂正です。 MPSEND送信実効速度向上のため、 １－１）バッファー数追加：（３＊垂直同期間隔／Wi-Fiの送信間隔）＋α １－２）関数型MPSEND追加：バッファーオーバーフローをエラーとせず、戻りとして処理結果を返す。または、空きバッファー数取得機能追加。 または、 ２）バッファー数追加：（２＊３＊垂直同期間隔／Wi-Fiの送信間隔）＋α を出来ないでしょうか。

５２行のSPHITSPは、衝突していないときは、－１を返します。 SPSの値を確認してみてはどうでしょうか。

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

SPHITSPのヘルプ１／３と３／３では不十分なのでしょうか。

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

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

食物連鎖の続編待ってます。（時間があればですが）

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

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

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

*実際の進捗とは関係ありません。

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

USE,LOADの順番になっていて、２回目以降はLOADしないようになっていれば、そのような症状になりますが、そんなこと無いですとね？

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