Petitverse

DIM A%[0]
GSAVE A%,1
ARYOP 1,A%,65536,A%
GLOAD A%,1,1
これで色反転できます。

65536（&H1000）引くと負数じゃん
けど
＞＞＞16bitより上の桁は無視するのでOK＜＜＜
って理屈かしら

そうです。

ツララさんへ

プチコン3号では実行前にコンパイルが行われています。
その際に命令のチェックとラベルや変数名のリストアップなどが行われるのですが、それと同時に定数演算は定数として扱われます。
つまり、コンパイル時に1<<24というのは16777216という値に変換されるわけです。
したがって、速度面の問題ならば全く気にする必要はありません。

さらに16777216というのを1<<24と記述することで文字数を減らせる上にビットシフトを行っているというのを明示できるため視認性の向上とミスタイプによるバグの確率を減らしてくれます。

要するにデメリットはゼロでメリットは盛りだくさんなのです。

あと、「高度サウンドユニット」という名称こそ付いていますが、ARYOP命令は端的に言えばSIMD演算を行う命令です。
非常に汎用性が高いので配列変数を使って大量のデータ処理を行う場合に様々な面で活用できます。
プチコン3号の配列変数は非常に遅いのですが、ARYOP命令を使って配列の処理を行うことで普通に配列変数の演算処理を行うのと比べて最大で50〜100倍程度の速度向上が見込めます。

しかし、ARYOP命令で扱える演算子の種類は少なくて簡単な演算でも複数のARYOP命令を組み合わせて使う必要があり、ARYOP命令がうまく使えなかったり、使えても思ったような速度向上ができないという場合もあります。
そういう場合に自分一人の力では難しくても多くの人で情報交換を行えばみんながARYOPを使いこなせるようになると思います。

せっかくの汎用性の高い命令群なのに「音関係だけ」に高度サウンドユニットを使うのは勿体ないです。

音関係で高度サウンドユニットの関数を使ったことがないなぁ(画像関係ばかり)^^;
小ネタ挙げておきます(既知だと思うけど)。

ARY_SUM(左上)：配列の合計を返す
SEQ_ARY(右上)：0〜N-1の数列を返す
DIF_ARYD(左下)：配列を比較し、不一致部分に1を格納した配列を返す
＃ARY_SUM、DIF_ARYDはUndo/Redoとかで良く使ってます。

ARYOPとかは、小さい配列では逆に関数呼び出しの時間の方が大きくなって遅くなることがある点に注意ですかね。

ARGB分離を速くするネタないかと色々試していたら、GSAVEに実数型配列を指定するとunsigned intのような値が返ってくる事実に気付いたので、32bit色でも16bit色のように、面倒なA分離をシンプルにできて、かなり速くなることが分かりました(^o^)

やはり16bit色で分離するのが一番速いと思いますが、それと大差ない感じでした。
ツール内で常に実数型配列でいろんな処理行うとか考えると重くなりそうですが、色分離したい時だけ使うとかすれば、有効かも知れません。
＃ARYOPでのA分離に色々悩んでた日々は何だったんだろう･･･^^;

R/G/B256階調の色数値だとしても、GRPに描いた時点で32階調(不透明度は2階調)に丸められてしまいますね(RGB(255,255,255,255)を描いてもRGB(255,248,248,248)に。RGB(254,128,128,128)を描いてもRGB(0,128,128,128)に)。

GRPにはどう頑張っても65536色までしか描けない(1ピクセル16bit分の情報しかない)ので、それを整数型配列でGSAVEしても、実数型配列でGSAVEしても、精度は同じだと思います。

GRPって「書き込むと画面にも表示できるようになる16bitメモリ」なので、GRP←→配列のGLOAD/GSAVEも16bitのほうが良くて、BASIC上で色データを操作するのに32bitのほうが便利なので配列アクセスに16bit←→32bit変換があるって感じです。

GLOAD/GSAVEの32bit←→16bit変換も内部では最初の書き込みの分離と同じようなことをしているので、画像を扱うならBASIC上は16bitのまま操作するほうが理論的には処理速度としては早いはずです。

GLOAD/GSAVEの配列側が32bitで色変換フラグが16bit物理コードのままの場合にどのような挙動するかは実験してみだとは思いますが、仕様としてあんまり期待した動作じゃないからそれを期待して実装すると今後のプチコンアップデートで仕様が変わる可能性も。
（多分ARGB=8888の上位か下位16bit→ARGB=1555でARかGBが無理矢理ARGB値になりそう）

ちょっと試してみたところ、実数型でも2進数でbit長32を超えなければ、普通に(整数型と同じように)GLOADできるみたいですね。まぁこれができなければ実数型でGSAVE→GLOADできないことになって「バグだぁ〜！」と騒ぎたくなってしまいます(RGB()やGSPOITが返しようのない値をGSAVEが(実数型配列に)返す時点でかなりバグっぽいと思ってますけど)。

それで、bit長32超えた場合はというと、POW(2,32)は#WHITEで、-POW(2,32)は0でGLOADされました。POW(2,32)は0になる(下位32bitだけ有効)かと思ってたんだけど違いました。

32bitでGSAVEした配列を16bitでGLOADしたら･･･どうなるんだったかな？^^;
たしか下位16bitになってたような気が｡｡｡忘れました。

今回GSAVEに実数型配列を指定すると符号無し32bit整数で格納される、ということからいろいろ考えてみましたけど、そもそもこの動作がバグだったら、将来変更されるかも知れませんね。実際のところどうなんだろう？昔からこの動作だったんだろうか？昔からの動作ならずっとこのままかも知れないし。う〜ん、気になる。

塗りつぶしや経路探索のアルゴリズムに高度サウンドユニットの命令って活用できないかな？