HSPTV!掲示板

gzoomの挙動について質問致します。
ちなみに投稿者の環境(OS)は Windows XP です(環境依存かもしれないので)。
下記のスクリプトを実行すると、「○◎△▽□◇☆×」の文字列とハイフンの列が上下2箇所に描画されます。
上側の表示に比べ、下側がぼけた感じに描画されてしまいます。
ハイフンの列の表示は異なって当然ですが、「○◎△▽□◇☆×」がぼけるのは納得いきません。
よろしければご意見お願いします。

#define MainID 0
#define TmpID 1
#define TestID_A 2
#define TestID_B 3
	
	TestString="○◎△▽□◇☆×"
	BarString="-------------------------------"
	
	buffer TmpID
	font msgothic,22
	mes BarString
	
	buffer TestID_A
	font msgothic,20
	mes TestString
	gzoom 200,20,TmpID,0,0,10*strlen(BarString),20
	
	buffer TestID_B
	font msgothic,20
	mes TestString
	gzoom 200,20,TmpID,0,0,10*strlen(BarString),20,1
	
	screen MainID
	gzoom 600,300,TestID_A,0,0,200,100,1
	pos 0,300
	gzoom 600,300,TestID_B,0,0,200,100,1
	
	stop

スクリプト説明(仮想画面を#defineによって定められたウィンドウIDの仮称で呼ぶ)。
TmpIDの地点(0,0)にハイフンの列を描画
TestID_AとTestID_Bの各画面の地点(0,0)に「○◎△▽□◇☆×」を描画。
TestID_AとTestID_Bの各画面に、TmpIDで示される仮想画面からgzoomによってハイフンの列を縮小描画。
その際、TestID_Bではgzoomのパラメータ8に1を指定し、ハーフトーン使用。
MainIDにTestID_AとTestID_Bの各画面の地点(0,0)から(200,100)の範囲をgzoomによって3倍描画。
その際、パラメータ8には共に1を指定し、ハーフトーン使用。

ちなみに、とりあえず回避する方法はいくらでもあります。
「font msgothic,22」を「font msgothic,20」に変えたり、ハイフンを一つ減らしたり・・・。
だからこそ謎です。

興味深い話題だったので試してみました。
TestID_Bは最初のハーフトーン適用で少し補完が適用されて
2回めのハーフトーンでさらに補間されているからではないでしょうか。
つまりID_Aは1回、ID_Bは2回ハーフトーンが適用されているので、
下側がボヤけるのは処理的には正常動作というようにも見えます。

フォントサイズを変えても私の環境では下側のほうが少しボヤける
ので.....、これはこれでokという気がしました。

＞nancotanさん
返答ありがとうございます。
ところで「○◎△▽□◇☆×」の表示部分については、
ID_A、ID_B共に1回しかハーフトーンは適用されていないはずなのです。
gzoomのハーフトーンを使った描画によって、
描画先の仮想画面の性質自体が変わってしまうということでしょうか。

その後しらべてみたのですが、ちょっとプログラムの解釈を間違っていました。
いなえさんの説のほうが正しいかもしれません。
ちょっと視点を変えてフォントのボケかたを調べてみると
p2を省略してもサイズによってアンチエイリアスが適用されてしまうようですが
このへんにも問題があるのかもしれませんね。

不思議に思った＆興味を持ったので、
BarStringのハイフンの数を増やして実験していた所、変な現象が…
文字列の長さが65バイト以上になってから、拡大コピーした右から余計に黒い棒が出てきました！

バッファをスクリーンに変えてチェックした所、
どうやらTestID_Bでのハーフトーンを用いたgzoomの時点で生じているようです。
これは…何なのでしょう？
今の問題と何か関係あるのかな…？

ちなみに実験結果としては…
ハイフンのサイズを0から100までの間で変化させたところ、
長さが27で初めてボけ、
以下、サイズが、
29,31,37,39,41,43,47,49,51,53,57,59,61,62,63,67,69,71,73,74,78,79,81,82,83,86,87,89,91,93,94,97,98
の時にボケました。
切りの良くないサイズだととボケるのかな？（てきとー）
でも理由が解らん…う〜ん…

＞uhouhoさん
「黒い棒」について。
gzoomのハーフトーンを用いたコピーでは、
ウィンドウの領域外をコピー元に指定するとその領域外が黒くコピーされるようです。
ちなみにgcopyやハーフトーンを用いないgzoomでは領域外はコピーされず、
grotateやgsquareではウィンドウの領域に合わせて勝手にコピー元が修正される模様。
なお、実験は下記のスクリプトで行いました。

#const BufferX 80
#const BufferY 40
#const CopyX 160
#const CopyY 80
#const CopyOX -40
#const CopyOY -20
#const ScreenX CopyX
#const ScreenY CopyY*5

;id1 赤塗りつぶし+緑斜線
	buffer 1,BufferX,BufferY
	color 255,0,0
	boxf
	color 0,255,0
	line 0,0,BufferX,BufferY

;id0 青塗りつぶし
	screen 0,ScreenX,ScreenY
	color 0,0,255
	boxf

;以下命令を変えて id0 に id1 を順にコピー
;その際コピー元領域には id1 の範囲外を含む
;なお、すべて等倍コピー
	gmode 0,CopyX,CopyY

;gcopy を使った通常のコピー
	pos 0,CopyY*0
	gcopy 1,CopyOX,CopyOY

;gzoom を使ったコピー(ハーフトーン無し)
	pos 0,CopyY*1
	gzoom CopyX,CopyY,1,CopyOX,CopyOY

;gzoom を使ったコピー(ハーフトーン有り)
	pos 0,CopyY*2
	gzoom CopyX,CopyY,1,CopyOX,CopyOY,,,1

;grotate を使ったコピー
	pos CopyX/2,CopyY*3+CopyY/2
	grotate 1,CopyOX,CopyOY

;gsquare を使ったコピー
	x0=0,CopyX-1,CopyX-1,0
	y0=CopyY*4,CopyY*4,CopyY*5-1,CopyY*5-1
	x1=CopyOX,CopyOX+CopyX-1,CopyOX+CopyX-1,CopyOX
	y1=CopyOY,CopyOY,CopyOY+CopyY-1,CopyOY+CopyY-1
	gsquare 1,x0,y0,x1,y1

	stop

なお、新たに分かったこととしては、
TestID_Bへのgzoomの描画地点によってもボケる場合とボケない場合があるようです。
元のスクリプトでは前の行の「mes TestString」で描画地点が(0,20)に移動していますが、
その間に例えば「pos 0,21」とするとボケませんでした。
実験ではnを整数として描画地点のy座標が20+6*nの形の時のみボケるようです。
また、x座標によってもボケない場所があります。
ますます謎です。

＞いなえさん
> gzoomのハーフトーンを用いたコピーでは、
> ウィンドウの領域外をコピー元に指定するとその領域外が黒くコピーされるようです。
> ちなみにgcopyやハーフトーンを用いないgzoomでは領域外はコピーされず、
> grotateやgsquareではウィンドウの領域に合わせて勝手にコピー元が修正される模様。
> なお、実験は下記のスクリプトで行いました。
詳しい解説ありがとうございます！
なるほど、お蔭様で黒い棒の方の疑問はスッキリしました〜
ということは、コレは関係なさそうですね(^^;

> なお、新たに分かったこととしては、
> TestID_Bへのgzoomの描画地点によってもボケる場合とボケない場合があるようです。
> 元のスクリプトでは前の行の「mes TestString」で描画地点が(0,20)に移動していますが、
> その間に例えば「pos 0,21」とするとボケませんでした。
> 実験ではnを整数として描画地点のy座標が20+6*nの形の時のみボケるようです。
> また、x座標によってもボケない場所があります。
ほ、ホントですね…（汗
一体何なのだ…何か解ったらまた書き込みます。
（その間に金田一君が出てくる事を祈りつつw）