高度サウンドユニットの実装がうまくいかない・・・ すえさんの実装のパラメータを変更するのは脳内イメージが追いつかず上手くいかない・・・ 上位ビットの削除方法がわからず途方に暮れる。

あ、高度サウンドユニットを使用した画像処理の話です。 RGBAと格納された32bitの色情報から各要素を取り出したいのですが うまくいかず。画素によってオーバーフローエラーをARYOPが出してしまう。 論理演算のようにシフトされたビットを切り捨てできない？

#AOPLIPはアルファ通常合成処理に使えそうなのでメモ、 まだうまく行ってないけど #AOPLIP,OUTV,COL1,COL2,α値/255

高度…がよくわかっていないので的はずれかもですが。 32bitカラーはARGB(8:8:8:8) 16bitカラーはRGBA(5:5:5:1) 要素毎にわけるとしたらこれでよいのでは？

論理演算ではそれでやっているのですが ARYOP演算だと論理演算が使えないので 乗算値か１／乗算値をかけてビットシフトの代わりにしています。 問題は、論理演算ビットシフトと異なり、桁溢れが起こるとオーバーフローエラーになってしまうのです 。すえさんはこの問題をなんか回避してたのですが、理屈が分からないのです。どうにか解決したいのですが・・

多分負の値になる時おかしくなるので、右シフトだとこんな感じかな。 ARYOP #AOPDIV,B%,A%,1<<16 '16bitシフト ARYOP #AOPCLP,C%,A%,-1,0 '負の値のみ-1,それ以外0 ARYOP #AOPMAD,D%,C%,-65535,B% 'B%のうち負の値のみ65535足して補正 左シフトも似たようなことが必要かと。32bit目まで到達する場合は一旦負にしてから掛け算でシフト。 もっといい方法ありそうな気もするので、すえさんのコード見てみたい:)

A%<<16。もっといい方法あるような気がもりもりするけど浮かばないっす。 ARYOP #AOPCLP,B%,A%,&H7FFF,&H8000 ARYOP #AOPSUB,B%,B%,&H7FFF '&H8000以上を1,それ以外を0 ARYOP #AOPMAD,C%,B%,-&H10000,A% '&H8000以上を負数に ARYOP #AOPMUL,D%,C%,1<<16 '16bitシフト 整数のオーバーフローつらい

ARYOP #AOPDIV,B%,A%,-&H8000 '&H8000以上を-1,それ以外を0 ARYOP #AOPMAD,C%,B%,-&H10000,A% '&H8000以上を負数に ARYOP #AOPMUL,D%,C%,1<<16 '16bitシフト 1命令減りました。あとは頭いい人に御願いしたい:)

https://miiverse.nintendo.net/posts/AYMHAAACAAADVHlKIfIOJA すえさんのソースはここのトピを参照しました。 3DSいじれないのでまた晩に

juhsyの画素情報、順番を誤ったかもしれない、（GSAVEの32bit画像と同じでない！？） だとすると、不覚。orz

ちゃんと検証してないので間違ってたらスミマセン すえさんの方法は、最上位ビットを含むA成分を先に抽出し、32bitの色情報からA成分を引いておくことで、上位8bitを0にクリアしておく、というとこがポイントかなーと思いました(゜ロ゜)

もしjuhsyの内部画素情報がARGBの順でなくRGBAの場合でも、先にR成分を抽出すれば、同じようにできるような気がします(≧∇≦)b

ANDを使ったビット演算は値が分からない状態から特定のbitの値を取り出すのに有用ですが、上位のものから計算してすでに値が分かっている状態においてその分かっている値のbitの部分を削除する（1から0にする）のであれば単純にその値を引けば解決できると思います。 それとも、私が考えているものとは全然別の何かをやろうとしているのでしょうか？

処理した画像データをまとめたあとそのままGLOAD(32bit)に流し込みたいのですが、うまく映らないのでちょっと失敗したかなぁ・・・

朝のミスってるとこあったので、3DSで実行して確認したやつ貼っておきます:) ついでにコメント入れて先頭8bitのコードを取り出す/戻す処理に変えときました。あとAOPMULが早いそうなのでAOPDIVやめたり。 すえさんのコードも見ましたがやってることはほぼ同じですね。符号なしから符号ありに変換するのはこっちが速いと思うけど実測してません。 …上位ビットの削除って、符号ありだとシフトの時1で埋まって困るって話で良かったのかな…。

よ・・・読めない・・・(；´Д｀) (コメントが暗いので)

皆さんありがとうございます、自分は頭のなかでイメージがつかむまでちょっと時間がかかるので、もう少々お待ちください。 (ソースコードをビットの動きとしてイメージできるまでタイムラグがある)

失礼しました…。コピペします:) 24ビット右にシフトした時0〜255が返ってきて欲しいんだけど、符号付き整数だから-128〜127になってしまう。128〜255が-128〜-1になってるので、負の時だけ+256して0〜255に変換する。これをARYOPだけで実現する。 '右シフト 'A%=A%>>24 ARYOP #AOPMUL,A%,A%,1/(1<<24) 'A%が負の時だけ-1、それ以外は0 'IF A%<-1 THEN B%=-1 ELSEIF A>0 THEN B%=0 ARYOP #AOPCLP,B%,A%,-1,0 'A%が負の時だけB%には-1が入っている。-256倍して加算することで負の時だけ+256。 'A%=B%*-256+A% ARYOP #AOPMAD,A%,B%,-256,A%

'24ビット左にシフトしたとき、128以上の整数は符号付き32bit整数の範囲を越えoverflowとなる。128〜255の時だけ-256して-128〜-1に変換する。 'B%=A% DIV 128 '128〜255の時だけ1に、0〜127の時0 ARYOP #AOPMUL,B%,A%,1/128 'A%=B%*(-256)+A% 'A%が128以上の時だけB%には1が入っているので、-256倍して加算することで128以上の時だけ-256 ARYOP #AOPMAD,A%,B%,-256,A% '左シフト 'A%=A%*(1<<24) ARYOP #AOPMUL,A%,A%,1<<24

ごめんなさい、拡大して読んでました。 いま、2行目ARYOP行までやっと理解。 3行目ARYOP行がイメージができてない。

図に起こしてみて納得できたようなつもりになっている。 納得したに違いない！(ﾟ∀ﾟ)(←実装しろよ)

わたしも、やっと理解しました＠＠； Aの成分が&HFF固定で、RGB成分を&H000000～&HFFFFFFまで変化させ、それぞれ1<<24で割ったとします ARYOPの計算中は実数で計算されるので &HFF000000/(1<<24)=-1.00000000 &HFF000001/(1<<24)=-0.99999994 ... &HFFFFFFFE/(1<<24)=-0.00000012 &HFFFFFFFF/(1<<24)=-0.00000006 になるんですけど、これをそのまま整数変数に代入しちゃうと、小数点以下が切り捨てられて &HFF000000/(1<<24)=-1 &HFF000001/(1<<24)=0 ... &HFFFFFFFE/(1<<24)=0 &HFFFFFFFF/(1<<24)=0 になっちゃうんですね（続く）

そこで、256足して正の数にしておくと &HFF000000/(1<<24)=255.00000000 &HFF000001/(1<<24)=255.00000006 ... &HFFFFFFFE/(1<<24)=255.99999988 &HFFFFFFFF/(1<<24)=255.99999994 となるので、小数点以下を切り捨てた時、どれも同じ255になってめでたしめでたし！ というのが、すえさんの3550行で一旦256を足して、次の行ですぐ256を引いてる理由のようです(≧∇≦)b

あー、なるほどすえさんのソースでAOPMADでOP3に1<<8をつかって直後に引いてる意味がよくわからなかったのですが、そういうことですか！！ (わかった気になっている(ﾟ∀ﾟ))

切り捨て処理の事忘れてた！ テスト漏れです、お恥ずかしい……＞＜

ARYOP に論理演算系のオプションがあればいいんじゃないかなーって思うけど、 そもそもサウンド用な目的だとそんな感じには使わないからしょうがないのかなぁーって。 ※一応有料オプションだし、ARYOP前提なプログラムだらけになっちゃっても実行できない人いそうだし

や、EXTRAFUTURE変数で「あれば使う」プログラムもできますし 何より遅い配列演算が改善される数少ない方法なのです。 これをサウンド専用にしてしまうのはもったいない感があります

できた！！、サンプルソースSBKEY:「V3XK338F」 左シフトは必要なかったのね 2日も唸ってしまった・・・

おおおおおお、しゅごい！！(゜ロ゜) 私も、ARYOPに論理演算あればいいな～と思います！ いっそ、「高度グラフィックユニット」とかでも(゜◇゜)

あまりシャチョサンは乗り気ではなかったようです・・・(´・ω・｀)

わかったこと 1:整数変数「変数名%」は32bit整数だが範囲はおよそ2.1億～-2.1億 2:論理演算の代わりに乗数を掛けたり割ったりすると実数計算される 3:演算オーバーフローエラーあり

juhsyに組み込んでみた。 まだおもったより早くならない・・・ 上画面全域で5fpsぐらいかなぁ・・ 分離とアルファ処理全部で30ステップぐらいARYOP使用

メモ、画像合成にAOPLIPを使用するときに、OP3は実数型である必要がある (小数点以下なので)

実数型と整数型のARYOP計算だめなのか？

配列のprintがtypeMissmatchになる・・・何故？

高度サウンドユニットの関数作ったらどれくらい需要があるのかしらん？ SULayMergeとか・・

MYU314さん、みなつさん、わさびんさんありがとうございました。

全体の処理としてARGBの分離に時間がかかっているので範囲が同じなのならばRGBは結合せず調整最後に結合すればスライダーによる連続した処理は高速化できるかな。

ブラシ描画に応用したいけど描画範囲が不定なのでどう実装したらいいのか思いつかない

RGB分離結合をアタマと末尾のみにしたら、400*240で15FPSまで速度向上