3.3.0に更新して、自作のプログラムをチェックしたら、いくつが画面が乱れるものがありました。PCから転送した画像で、かつ、サイズが512×512じゃない画像をLOADで読み込むと、なぜかX軸だけ1つ飛ばしたような、スキマのある画像として読み込まれてしまいます（添付の画像の状態）。 同じ転送画像でも、512×512ならば問題が発生していないので、バグだと思います。

ただの内部仕様の変更でそうなっただけで、PCからの画像転送は元々想定外だからバグとは違うのでは？ それともGCOPYなどで512x512以外の大きさで画像をコピーするとそうなると言うこと？ それだと完全にバグっぽいですがw

今までのバージョンアップでも、それまでできていたことができなくなる現象があって、時には仕様変更だったり、時にはバグだったりしたので、今回は私見としてバグと捉えた次第です。仕様変更ならば、あきらめるより仕様がないですけどね(^^;)。

仕様変更じゃないかねぇ

＞れいさん 「そうなるようにした」のか、「そうならざるを得なかった」のか、どっちなんでしょうね。「そうなるようにした」のなら、あるいは（想定外の用法である）PCからの転送への牽制…なんて捉え方もできてしまいますが…。

何か内部処理を変更したら、想定外の形式のデータがたまたまそうなった。では？ 牽制？ならもっとちゃんとした対応をしそうな気がします。 PCからの転送でも512x512なら問題ないなら牽制ではない様に思えます。 今まで画像縦横サイズをチェックして処理をしていたところを、もともと512x512サイズが前提の仕様なら、可変対応の処理は無駄なので無くして決め打ちで512x512として処理を効率化？したとか？

どういうコードで再現するの??? ウチの 128x128 lena 様は変化ありませんが??

GSAVE経由で保存したデータも 引き伸ばされるみたい。 少し残念です。

仕様変更でバグってますね…。 牽制というか、今まで自動で変換してくれてたのが、厳密になった感じでしょうか。 おかしくなるデータについては一旦配列に読み込んだあとGLOADで描画すれば問題ないと思います。 P/RECVは512x512の時はSAVE"GRP0:xxx"で画像保存、それ以外はDATで保存だったんですけど、 整数型配列の場合は2ピクセルずつ詰めて保存しなきゃいけないようです…ようは16bit整数のバイト列にしなきゃいけないようで。 (幅が奇数の時は1ピクセル分ダミー入れる) P/RECV2なら456行あたりでその判定やってますんで、常に512x512扱いにして凌いでいただければ。 この仕様にするなら16bitで詰め込んでくれるGSAVE/GLOADが欲しいなぁ。

＞Godotさん ただ、X軸に異常が起こるというのは、逆に言えば、Y軸は正常に読み込みが反映されているってことですよ。512×512の固定処理（？）なら、どっちの方向にも伸びたり飛んだりする異常が起こりそうですが。 ＞MIKIさん 転送した画像を、プチコン上で再度保存すると、元のサイズがどうあれ、（余白を追加して）512×512画像として保存するため、異常が発生しないものと思われます。今回異常を起こしている画像データは、転送したままのデータなんです（そのほうが容量が軽く済んだので）。読み込み命令は、「LOAD "GRP4:画像ファイル名",0」です。 ＞マギーさん 近い現象は、GSAVEなどで配列に読み込んだ画像をGLOADする際に、範囲指定を間違った時のアレですね。でも、やはりX軸だけ、というのが異常なんですよねぇ…。

＞myu314さん それがですねぇ…。「LOAD "DAT:〜」で読み込もうとすると、Type mismatchって怒られるんですよ。ちなみに「P/RECV2」を使わせていただいてまして、読み込み完了後に表示されるプレビューは、正常に表示されます。でもそれを保存して「LOAD "GRP4:〜」するとX軸トビに…。

>まげさん 画像と同じサイズの二次元配列を作ってから読み込めば大丈夫だと思います。 VAR F$="DAT:TEST.DAT" VAR A%[1,2],B%[1,2] SAVE F%,A% LOAD F$,B% :'A%と同じサイズじゃないとType mismatch 扱いにくいしバージョン間のことも考えると、P/RECVはSAVE"GRP0:xxx"で保存するように変更かな…。 画像の部分保存、対応して欲しいなあ

＞myu314さん 二次元配列！　そうだったんですね〜。無知でした〜(^^;)。 ということで、おかげさまでリカバリーできそうです。大感謝です！！ でもホント、画像がちょっぴりなのに、512×512サイズを食ってしまうのは、罪悪感があるんですよねぇ(^^;)。

3.2.1のときは、 GSAVE～ で切り出したデータを SAVE"DAT:～" で保存したものを LOAD"GRP～" で、読み込むと 正常に表示されていたんですけど 3.3.0では、引き伸ばされてしまいます。 せっかく、オフセットロード機能がついたのに ちょっと、惜しいかなと思って。

＞マギーさん その場合、 LOAD "DAT:〜" で配列（一次）に読み込んでから、 GLOAD〜 で、正常に描き出しませんか？ ところで、おそらくそのオフセットロード機能の追加が、今回の現象の火種じゃないかと、私はニラんでいます(^^)。

DATファイルは、次元が一致していないとエラーになるみたいです。 2次元配列に読み込んでも GLOADのところで 元の幅と高さがわからないと きちんと表示することが 難しかったのですけど 3.2.1の LOAD"GRP～" だと、それが簡単にできて さらにオフセットロードが使えれば もっと便利かなと…。

LOAD"DAT:～" で、読み込む配列は、例え2次元でも 次元数さえ合っていれば 自動で大きさを調整してくれるみたいです。

＞マギーさん あ、失礼しました。できない、じゃなくて、プチコン3号へのご要望的なお話なのですね。配列も、一次に限りませんでした。重ねて失礼しました。

いえ、お気遣いありがとうございます。 こうやってコメントしている合間 プログラムしているときに 読み込んだ配列の 幅と高さを求める方法を見つけたので (原始的な方法です。) 結局、 LOAD"DAT:～" で、対処することにしました。 でも、またバージョンアップで 仕様変更になると 今やっているこれも無駄になるかも…。

＞マギーさん まぁ、OSのバージョンが上がると不都合が生じるソフトが出るのは世の常ですから、こまめに対応してくしかないんでしょうねぇ。と思って対応したら実はバグでした…なんてのは困っちゃいますが(^^;)。

GSAVEでFALSE（32bit論理色変換あり）で実数型配列に保存すると、不透明のピクセルについて、整数化すると32ビットを超えるような値が入るようです。ちょうど256^4がプラスされた値（32ビット超の次ビットが1）です。整数型配列に保存すれば、32ビットに収まる数値になります。 3.2.1ではどうだったのか覚えていないのですが、32ビットを超える値は返していなかったような……。 myu314さんの書いている16bitでパック化もそうですが、GRPファイルのフォーマットが何やら拡張されていることと関係がありそうです。 圧縮対応？（SYSにあるデフォルトのDFEBG.GRP, DFESP.GRPのファイルの512x512なのにサイズが80000バイト以下だし、ACLSが速くなっている） カタログIP対応？（カタログIPのビットマップは保存できない仕組みになっているらしい）

＞Oskarさん 32ビットを超える値、返さないどころか、文法ミス扱いします…(^^;)。

16進定数は整数型32ビットってことですねｗ 32ビットを超えていてもGLOADにはそのまま渡せるようですが（キャプチャなし）、グラフィック命令の色引数では弾かれました。 整数だけなのに実数配列に格納するな、ってのはそうなんですが、ちょっと意味のない仕様のような気がする…… （キャプチャがまずかったので削除して再コメントしました）

3.2.1で実験してみました。 そのあたりは、同じ処理みたいです。

マギーさん、実験ありがとうございます。アップデートに関係なかったんですね。 GSAVE FALSEで描画時と違うARGB値が入る仕様は納得なのですが（表示は16ビットなので）、整数で33ビット以上になる値が来るのはどうも合点がいかないです。