HSPTV!掲示板

HSPで半透明コピーの方法といえばgmodeのモード3or4or7を使ったり、picloadでアルファブレンド付きのPNG画像を読み込んで直接合成するという手段があります。
他にもhgimg3などのプラグインを使えば可能ですが、ここでは標準命令だけを使った方法で話を進めたいと思います。

さて、本題ですが。
HSPの標準命令だけで半透明な白い画像を同じ座標に重ねて何度も描写すると、なんと黒くなっていきます。
私の頭の中では半透明な白いものを重ねたら白くなっていくと思っています。
実際、画像編集ソフトで半透明な白い画像を複数重ねてみると白くなっていきました。
しかしHSPでは最初にあげた標準命令を使った4つの方法では全て黒く変化しました。
このように黒く変化しないようにするにはどうすればいいですか？

以下に参考スクリプトを貼っておきます。

buffer 1, 500, 250
color 1, 1, 1
boxf 250, 0, 500, 250
gsel 0
gmode 7, 250, 250
repeat 256
	gcopy 1, 0, 0, 250, 250
	await 10
loop

もしかすると私の開発環境が悪いのかもしれないので、開発環境も記載します。
OS:WinXP Pro SP3
GPU:GTX460
OpenGL:4.3
HSP:3.4beta2(3.32aでも動作確認済み)

モード3でコピーした場合

buffer 1, 250, 250
gsel 0
gmode 3, 250, 250, 1
repeat 256
	gcopy 1, 0, 0, 250, 250
	await 10
loop

buffer 1, 250, 250
gsel 0
boxf
repeat 256
          gmode 3, 250, 250,cnt
	gcopy 1, 0, 0, 250, 250
	await 100
loop

gmode　３の４番目をふやすのだ

>>^^さん
gmodeのモード3or4ではその方法で解決できるんですね。
ありがとうございます。
では、モード7やpicloadで半透明な白い画像を上手く重ねるにはどうしたら良いですか。

ブレンド率が２以下だと黒くなるようですね。３だと微妙なところ。
おそらく計算誤差によるものだと思います。端数の丸めによる影響です。

とりあえずの回避策としてはブレンド率を大きくしてください。
また小さいブレンド率を何度も重ねないようにしてください。（階数を減らす。）


それにしても、白にはならないんですが、真っ黒にもはならないはずなんですけどね。バグ？

バグっぽいですね。

不透明度が 0〜255 の値を取る場合のアルファ合成はこういう計算。

　合成後色 = ( 合成元色 * 不透明度 + 合成先色 * (255-不透明度) ) / 255

不透明度が1の時の計算。

　( 255 * 1 + 255 * (255-1) ) / 255 = 255　○
　( 255 * 1 + 255 * (255-1) ) / 256 = 254　×

こういうちょっとしたミスならありえるかな〜、と思いました。

画像編集ソフトで、画像を何度も重ねて、αチャンネルをすべて255にしてからgmode 7を使えば黒くなりませんよ

バグというより、意図的に速度を稼ぐために÷255ではなく÷256（8ビット右シフト）になってるようです。

http://dev.onionsoft.net/trac/browser/trunk/hsp3/win32gui/hspwnd_win.cpp#L1388

	// gcopyのmode 3によるコピー部分
	case 3:
		{
			// …略…
				// ↓実際のαブレンド部分
				ha=(((short)*p)*dstht>>8) + (((short)*p2++)*srcht>>8);
				if (ha>255) ha=255;
				*p++=(BYTE)ha;
			}
			p-=tofs;p2-=sofs;
		  }
		}
		return;

>>GENKIさん
確かに真っ黒まではいきません。
若干語弊がありましたね。
申し訳ありません。
ブレンド率を上げれば目立たなくなりますが、やはり灰色にはなってしました。

>>名無しさん
よく分からないので、もっと詳しく教えてください。

>>Roshさん と 3kさん
なるほど・・・。
ということは解決は難しいのですか。

> ブレンド率を上げれば目立たなくなりますが、やはり灰色にはなってしました。

計算上、ブレンド率255より小さい値では白になりません。灰色で正解です。（1だと私の所では黒になります。）
エクセル等で自分で確認計算してみるとわかると思います。
また小数点のまるめまで考慮すると、ある値に到達するとそれ以降は同じ値が続くことが確認できると思います。


> バグというより、意図的に速度を稼ぐために÷255ではなく÷256（8ビット右シフト）になってるようです。

なるほど。
ブレンド率低いから誤差が出ても目立たない問題ないからってことなんでしょうね。

>>GENKIさん
しかし半透明の白い画像をpicloadを繰り返して重ねても灰色になっていきます。
画像編集ソフトでは白になっていきますが。
計算上合っているとの事ですが、よく分からないので詳しく説明をお願いします。
そして何とかこの問題をクリアするにはどうすればいいのでしょうか・・・。

buffer 1, 250, 250
gmode 7, 250, 250,100
boxf
repeat 256
	gsel 1
	color cnt,cnt,cnt
	boxf
	gsel 0
	gcopy 1, 0, 0, 250, 250
	await 10
loop

gmode 7使った事ないから、実際これでどうなるかはわかりませんｗ

>>葡萄色(元GrapeColor(DION))さん

#include "a2d.hsp"
*開く
SCREEN 0,1280,720
	boxf
	dialog "png",16,"画像"
	alCreateImageByFile 0,refstr
	alCreateImageByFile 1,refstr
		repeat 8
			title ""+cnt
				redraw 0
					alCopyImageToImage 0,1,0,0,,,0,0
					alCopyImageToScreen 1,0,0,0,,,0,0
				redraw 1
		loop
		title "処理終了"
			button "保存",*保存
			button "開く",*開く
	stop

*保存
		dialog "png",17,"画像"
		alSaveFile refstr, "image/png", ,,,:Dialog stat
		title "保存終了"
		stop

png画像のαチャンネルをすべて255にするプログラムです。
この処理を施したpng画像にgmode7を使った場合、黒くなりません。

あ、すみません。よくスレを読んでませんでした・・・
真っ白な画像にgmode7を使うと黒くなるってことだったんですね。てっきり普通の画像に使ったのかと・・・
次からはスレもちゃんと読むようにします・・・
前の書き込みは忘れてください；

上手くやる方法はどうやら無さそうですね。
解決はしていませんが、解決扱いにします。