HSPTV!掲示板

こんにちわ（＾＾／
No.1662の「VRAMデータについて」を見て、わたしも勉強させていただきました☆

そこで、
>究極なのは、VRAMに直接配列参照を行いビット演算を行うことです。
>広域のメモリ操作命令を使用するのも有効です。
>これならば恐ろしい程の処理の高速化が期待できます。
>しかしこの方法は、アルゴリズムによって限られた状況下でしか行えない事が多いです。
とあるのを見て、どういう方法なのか知りたくなりましたΣ（￣△￣；
一体、どんな方法で、どのくらいの高速化ができるのか、教えてもらえないでしょうか？
お願いしますっ（~o~！

一応、色々やってみたのですが、よくあるサイズ640*480の画像の場合、
640*480=307200 // ピクセル
307200*3=921600 // R,G,B
ですよね。でもVRAMの配列要素数は、その４分の１である230400しかないです。

それは何で？かは置いておいて、それでも、repeat-loopで変更すると、
230400回のループ・演算が必要になってしまいます。
なんか、力技みたいのしか思いつかないので、
是非参考にさせて貰えれば嬉しいなぁ、と思ってます（＾ω＾？

>640*480=307200 // ピクセル => (1)
>307200*3=921600 // R,G,B => (2)
>ですよね。でもVRAMの配列要素数は、その４分の１である230400しかないです。

RGBの各要素は1バイトで、int型( の配列の一要素 )は4バイトだからです。

kz3さん、ありがとうございます♪

>RGBの各要素は1バイトで、int型( の配列の一要素 )は4バイトだからです

あっ、などほど、納得しました
16進整数 : 0x00000000〜0xFFFFFFFF
ですね（＾＾；

Dripです。

　理沙さん、こんにちは。
> > 究極なのは、VRAMに直接配列参照を行いビット演算を行うことです。
> > これならば恐ろしい程の処理の高速化が期待できます。
> とあるのを見て、どういう方法なのか知りたくなりましたΣ（￣△￣；

　についてですが、元スレッドにも書きましたように、やりたいことに対応したケースバイケースの
スクリプトを組上げる必要があります。「この命令や演算子を使えば高速になりますよ。」というものでは
ないことを念頭に置いておいてください。

　例えば「色の反転」を例にとって説明してみましょう。pget,psetを使用して全ピクセルの色を
判定して処理していたら途方もない時間がかかるのは、pget,pset命令が情報を人間にとって
処理し易い形にデータを加工する作業がはさまれているからです。
　VRAMとpeek,pokeを使用したとしても、やはり10進数のデータとして1バイトずつ処理している上に
１バイトずつ関数をはさんで処理しているため、pget,psetよりは早くとも鈍足です。
　ビット演算は、コンピュータにとって最も処理し易い演算で、データは２進数として考えます。
ビット演算についてはgoogleで「ビット演算」などと検索すれば、参考になるページが見つかると
思います。

　論より証拠。色の反転処理の処理速度比較プログラムを以下に示します。
pget,psetによる色の反転、VRAM+peek,pokeによる色の反転、VRAM+ビット演算による色の反転
を実際に処理させ、処理速度を比較してみます。凄まじい処理速度の差が体感できることと思います。

mref vram,66

pat="pget,psetによる反転","VRAM+peek,pokeによる反転","VRAM+ビット演算による反転"

dialog "pget,psetを用いて色の反転を行います。"
redraw 0
time=gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7)
repeat ginfo_winx:x=cnt
	repeat ginfo_winy
		pget x,cnt
		color 255-ginfo_r,255-ginfo_g,b=255-ginfo_b
		pset x,cnt
	loop
loop
res(0)=(gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7))-time
redraw 1
dialog ""+res(0)+"mSecかかりました。"


dialog "VRAM,peek,pokeを用いて色の反転を行います。"
redraw 0
time=gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7)
repeat ginfo_winx*ginfo_winy*3
	poke vram,cnt,255-peek(vram,cnt)
loop
res(1)=(gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7))-time
redraw 1
dialog ""+res(1)+"mSecかかりました。"


dialog "VRAM,ビット演算を用いて色の反転を行います。"
redraw 0
time=gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7)
repeat ginfo_winx*ginfo_winy-(ginfo_winx*ginfo_winy)/4
	vram(cnt)^=-1
loop
res(2)=(gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7))-time
redraw 1
dialog ""+res(2)+"mSecかかりました。"

cls
pos 10,10:mes "処理速度比較\n\n"

repeat 3
pos 20,cnt*30+50:mes pat(cnt)
pos 0,-20:mes ""+res(cnt)+" mSec.":pos 340-ginfo_mesx,cnt*30+50:mes ""+res(cnt)+" mSec."
pos 0,-20:pos 400,cnt*30+50:mes ""+double(res(0))/res(cnt)+"倍高速化しました。"
loop

　いかがでしょうか。かなりの処理速度の差を実感できたと思います。
しかし、これを見てわかるように、ビット演算で処理速度が向上する状況は、かなり制約を受けます。
どんな処理でもビット演算に置き換えることで高速になるとは限りません。
VRAMを使わないほうが高速になることも十分ありえることを覚えておいてください。

尚、今回の色の反転については、

buffer 3:gsel 0:time=gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7):redraw 0

gmode 6,ginfo_winx,ginfo_winy,256:gcopy 3:redraw 1
dialog ""+((gettime(4)*3600000+gettime(5)*60000+gettime(6)*1000+gettime(7))-time)+"mSecかかりました。"

が最も高速なので、単純な色の反転のためにVRAMを使用する意味は全くありません。

返事が遅くなってすいませんっ（＾＾；

Dripさん、貴重な情報をほんとにありがとうございます☆
ＨＳＰでこんなに早く画像処理ができると思ってもみませんでした。
改めて、ビット演算の重要さを思い知らされました（￣w￣）

一応、結果ですが、
反転は、ビット演算で約50倍前後違いました。(WinME)
時間で言えば、0.13秒前後ですっ！

例えばR,G,Bの情報を個別に取り出す、

mref vram,66

dim rgb,3,3
rgb(0,0)=0x00FF0000,0x0000FF00,0xFF0000FF   ;R
rgb(0,1)=0x0000FF00,0xFF0000FF,0x00FF0000   ;G
rgb(0,2)=0xFF0000FF,0x00FF0000,0x0000FF00   ;B

redraw 0
repeat ginfo_winx*ginfo_winy*3/4
    // 赤を取り出す
    vram(cnt)&=rgb(cnt\3,0)
loop
redraw 1

などでも、配列参照に時間を取られるだけで、
全体で0.18秒程度で処理できました（＾＾

確かにケースバイケースではありますが、
一工夫で様々な処理が高速化できそうですし、用途は無限にあると思います♪

ただ、Dripさんの、
>どんな処理でもビット演算に置き換えることで高速になるとは限りません。
の言葉を頭に入れて、色々やっていきたいと思っています（＾＾v
☆どうもありがとうございます☆