2次元配列、ループシフト関数「ARY_SFT」

ループシフト関数「ARY_SFT」 sbkey:RDCEA3Q4 任意の2次元要素数の配列を x軸、y軸の要素数分シフトさせます GSAVE等でセーブした配列に有効です ARYOPのガウシアンフィルタ作成の過程で ずらし配列生成の副産物として作りました。 ARYOP等は特に使用してません 配列の位置のみを弄っているので数値等は変化ありません このため、ARYOPでRGB分離した配列にも使用可能です。 サンプルソースはタッチで無限にループシフトするプログラムです GSAVEでセーブした画像配列をシフトさせ シフトした配列をそのままGLOADに流し込んでます

結構高速にできたと思うので使ってみてください

引数のオプションで、シフトしてはみ出たデータの処理を 0:0で埋める 1:対角の要素に移動 の選択可能

RINGCOPY使ってる訳じゃないのね。 てか、RINGCOPYだと縦方向にシフトする(スクロールする)のは簡単だけど、横方向が面倒か。 てか、RINGCOPYに限らず画像配列横にシフトすること自体面倒だということに気付いてきた今日この頃。

RINGCOPYは1次元の方が簡単になる希ガス。 横方向→ドット分ずらす 縦方向→ドット×横ピクセル

二次元配列を一次元配列で受けて copy ・・・・ と思ったけど copy に同じ配列渡すとバグバグだからかえって面倒かな?

高度サウンドユニットの新しいのスレッド立てたい・・・

ああ、ringcopyなんて便利な命令があるのか。 同じ配列渡してもバグらないのであれば、 一次元配列で受けて ringcopy が最速のような気がしますね。

画像配列を横にズラすのに役立つかもしれない小技。 GSAVE -1,0,W,H,G%,0 ってすると、左端の画像データは0としてG%に格納されるみたい。

現状ARYOPはRGB分離に時間がかかっているので、シフト配列をGSAVEで取得するのは、ARYOP使用時には得策ではないかも

そっか、RGB分離のためのARYOPの回数自体を減らすためのアイデアだったんですね(今更理解^^;)。 RINGCOPY、2次元配列での動作よく分からなかったので試してみたら、横シフトになりました(^o^) 但しコピー先、コピー元は別配列じゃないとダメみたい。 DIM G%[H,W],O%[H,W] GSAVE 0,0,W,H,G%,0 RINGCOPY O%,1,G% ＃O%には1ドット右にズレた画像が入る。 コピー先コピー元同じにできたらもっと便利だったんですけどねぇ。

やっぱり一次元で同じ配列を渡すとバグるのな(memmove(3)的な動作ではない) var z%[0] gsave z%,1 ringcopy z,512*8,z,0,512*240 gload z%,1 ガクッ・・・・

元画像は非破壊で色々弄くりたい・・・

「ARY_SFT」 juhsyに組み込んだら特定方向で1ピクセルずれてた・・・・orz なおしたい。。

今朝気付いたんだけど私勘違いしてました。 画像配列横シフト全然面倒じゃなかったですね。 縦シフトもそんなに面倒じゃないし。 何故か1ビットだけずらしたら画像ななめに傾いちゃうんじゃないかと思い込んでました^^; なので無理にRINGCOPY使うこともないかも。

そうですね、ループシフトの場合はみ出た部分が次の行頭に移動してしまうので、そこだけ一行上下する必要がありますが。

報告 画像配列シフトにRINGCOPY使ってみましたが、BIGではCOPYより遅かったです。処理考えればCOPYの方が単純そうだから、当然と言えば当然の結果なのかな。まぁ使用ケースによって変わってくるかもしれないし、3号では違うかもしれないし、参考程度に。 ぼかし関数は、整えたら研究会の方で紹介させて頂こうと思ってます。 ＃3号の高度サウンドユニット持ってないことが ＃歯痒くなってきた^^; ＃戦略に乗るのはシャクだが買っちまうか。

＃なんか朝に勘違いに気付く^^; やっぱりCOPYでの画像配列シフトそれなりに面倒だったんですね。ぼかしでばかり考えてたから、1ドットずらして前の行末のドットが行頭にずれて来てても、端っこ切っちゃってたから簡単だと勘違いしてました。 なので、やっぱりRINGCOPY有効かもしれません。単純に同じドット数ずらしてコピーするだけの処理ならRINGCOPYの方が遅いかもしれませんが、ずれて行頭に来たドットを何とかするために複雑な処理が必要になるなら、RINGCOPYではその複雑な処理が要らない分、結果速くなるかもしれません。 縦シフト1次元、横シフト2次元で処理できれば、RINGCOPYだとすごく簡単な記述になります(^o^)

本当に簡単な記述になるか、作ってみました。 キー：WE2EAD ファイル：RING_SFT 左スティックでスクロール、Xボタンで終了です。 ミソは、2次元配列なら1ドットずらしても行末が次の行の行頭に行かず、その行の行頭に来るのと、コピー先オフセットにマイナス値を指定できるところです。これによりかなり記述を簡単にできました。 とは言っても、縦シフトは意地でRINGCOPY使ってやったのでちょっと強引です。あと3号では試せてないので速度どうなのか。速いと思うんだけど。 それと気になったのは、MIKIさんのおっしゃってた、COPYでコピー先/元同じだとバグってるっていうの、BIGだと大丈夫っぽいんですよねぇ。コピー先/元の配列内の領域かぶってても問題ないようだし。これはもうちょっと調べてみます。 ＃なんか脱線してきたかな?ぼかしでは結局 ＃RINGCOPY使う必要なかったし^^;

あ、いいアイデア思いついた! GRPリソース大量に消費しちゃうけど。 分離したARGBをgloadで変換せずにgloadで保存するのさ！（RGBバッファとして使用） これならシフト配列も簡便に取得できるし、 切り出し合成の手間がかからない！ 汎用性のある方法じゃないけど、少なくともjuhsyのいくつかの問題点をいっぺんに解決できそう！＼(^o^)／

つまり、可視ビットをムリヤリ立てるとRチャンネルはこういう表示になる ヤダ・・・丸見え・・・

ふっふっふっ。それ私も思い付いてました。不透明度捨ててたから丸見えにはなりませんでした(っていうか何も見えない)けど。あとGSAVE/GLOAD3回ずつが意外と遅かったです。 ＃っていうかmoh6anさんそれやりたくなくて ＃一生懸命COPY使ってたのかと思ってましたよ

えー遅いのかー、juhsyでは1-3のGRPページでんでん使ってないのでいいかと思ったんだけどなぁ・・・・でもまぁ足りないメモリが空きますし、サウンドユニット非搭載環境でも高速化の道がひらけたので良しとします(ブラシ要素を真面目に全計算してたので)

切り出しもcopy+オフセットループで取得したほうが圧倒的に速いか・・・・

RGBチャネルに32bit配列使うのが帯域がもったいないと考えてしまう末期

配列直接シフトにする前に、R,G,BそれぞれGSAVE/GLOADしてたから、COPYに較べると若干遅い感じだったかなぁ(いろんなバリエーション試しすぎて定かじゃない^^;)。 でもGRP使えればいろんな処理楽チンにできそうですね(座標があーだからいくつずらしてごにょごにょ、とか考えるの疲れる)。

なんかオフセット弄くればラスタースクロールとか作れるかな・・・・うねうねのやつ・・・

RINGCOPY使えば意外と簡単にできそうですね(^o^) やってみて下さい！(やってやってぇ～)