HSPTV!掲示板

この記事は投稿者により削除されました。
2007/10/21(Sun) 20:28:33

Dripです。

　Shinyaさん、ご回答有難うございます。返信が遅れ大変失礼をいたしました。
いただいたスクリプトなのですが、やはり画像データの回転には向かないようです。
（精度がgrotateより低くなっているようで、画像がガタガタになります。）
#global以下を次のプログラムに置き換えて実行してみて下さい。
「あ」という文字を90度倒した場合、少しずれて見えます。

#define CenterX ginfo_winx / 2
#define CenterY ginfo_winy / 2
	buffer 1,16,16:mes "あ"
	gsel
	tx=16+CenterX,16+CenterX,0+CenterX,0+CenterX
	ty=0+CenterY,16+CenterY,0+CenterY,16+CenterY
	DrawTexture 0, 1, tx, ty
	redraw 1
	stop

ＭＳペイントのような、単純な90度単位の回転を高速に行いたかったのですが・・
HSP3では無理なのでしょうか。

grotate 1,0,0,0.5*3.14,16,16

↑普通に正確な回転してるように見えるのですが・・・。

なるほど。
buffer 2,180,16 :mes "あいうえお"
gsel 0
gmode 0,180,16
pos 100,100: grotate 2,0,0,0.5*3.14,180,16-1
stop

16に-1してみたら正常に表示されました。これでいいのでしょうか？

Dripです。

　Asさんの方法では、正確な回転ができません。
（と最初のスレッドで申し上げたと思いますが・・

size=800
screen 3,size,size:a=""
repeat 57:a+="あ":loop
repeat 52:mes a:loop
screen 0,size,size:gmode 0,size,size
pos size/2,size/2:grotate 3,0,0,0

ご覧のように、grotate系の命令では、回転を加えなくともコピーに誤差が生じます。
コピーサイズを-1にしたところで画像サイズが増えるに従って誤差も何十ピクセルも増加し、
結局のところgrotateやgsquare等の命令は使用できません。
回転という概念ではなく、90度倒した正確なピクセルの置き換えをしたいのですが・・
もうVRAM+peek&pokeしか手がなさそうですが、これだと物凄く鈍足なんですよね；

>もうVRAM+peek&pokeしか手がなさそうですが、これだと物凄く鈍足なんですよね；
プラグインですればOKみたいです。
しかし...どれを使っていいやら(^^;

自分的に以下のプラグインがよさそうですね(^^;
http://www2.pf-x.net/~shink/

多分...C言語で作られているようです.

ぷまさまのNO7のmemcpyを使ったスクリプトも十分に速いと思うのですが、
もっと速いほうがいいのですか。

//http://hsp.tv/play/pforum.php?mode=all&num=4355 by ぷま
#module
#enum BUF1 =2
#enum BUF2
#enum BUF3
#deffunc nekkoro2 int n2id,int n2muki		;転送先ID , 回転方向(0=反時計 1=時計回り)
	gx=ginfo(26):gy=ginfo(27):sx=(gx&-4)+4:sy=(gy&-4)+4
	buffer BUF2,4,sx,0		:mref v3,66		;4ライン作業用VRAM
	buffer BUF3,sx*4,sy,0	:mref v4,66
	if (n2muki){
			pos 0,sy-1:gzoom sx*4,-sy,0,0,0,sx,sy
		}else{
			pos 0,0:gzoom sx*4,sy,0,0,0,sx,sy
		}
	buffer BUF1,sy,sx:gmode 1,1,sx
	s=sx*3*4					;v3のサイズ
	repeat sy
		memcpy v3,v4,s,0,s*cnt			;buffer 3に縦にコピー
		pos cnt,0:gcopy BUF2			;screen 2にコピー
	loop
	screen n2id,gy,gx,4|2:gmode 0,gy,gx
	gcopy BUF1,(sy-gy),(sx-gx)
	buffer BUF1:buffer BUF2:buffer BUF3
	gsel n2id,1
	return
#global

screen 0,,,0
	picload dirinfo(1)+"/sample/demo/sky_bg.jpg"

	nekkoro2 20,0					;screen 20に反時計方向に回転してみる

	gsel 0						;gselで選択
	nekkoro2 21,1					;screen 21に 時計方向に回転してみる
	redraw
stop

最初に Drip さん自身が書かれたスクリプトの機械語部分の下記の２行を

yoko. 7=$89c033f8,$558be845,$10828b08,$89000003,$518be445,$04598b0c,$8b01f283
yoko.14=$00031081,$42d20300,$2bdaaf0f,$e04589c3,$00107d83,$458b0c74,$2bd8f7e4

これ↓に書き換えてみて下さい。

	yoko. 7=$89c033f8,$558be845,$0C828b08,$89000001,$518be445,$04598b0c,$8b01f283
	yoko.14=$00010C81,$42d20300,$2bdaaf0f,$e04589c3,$00107d83,$458b0c74,$2bd8f7e4

すいません。ちゃんと右回転していませんでした。

すいません。
もう解決しそうですが、スクリプトを修正しました。

//http://hsp.tv/play/pforum.php?mode=all&num=4355 by ぷま
#module
#enum BUF1 =2
#enum BUF2
#enum BUF3
#deffunc nekkoro2 int n2id,int n2muki		;転送先ID , 回転方向(0=反時計 1=時計回り)
	gx=ginfo(26):gy=ginfo(27):sx=(gx&-4)+4:sy=(gy&-4)+4
	buffer BUF2,4,sx,0		:mref v3,66		;4ライン作業用VRAM
	buffer BUF3,sx*4,sy,0	:mref v4,66
	if (n2muki){
			pos 0,sy-1:gzoom sx*4,-sy,0,0,0,sx,sy
		}else{
			pos sx*4-1,0:gzoom -sx*4,sy,0,0,0,sx,sy
		}
	buffer BUF1,sy,sx:gmode 1,1,sx
	s=sx*3*4					;v3のサイズ
	repeat sy
		memcpy v3,v4,s,0,s*cnt			;buffer 3に縦にコピー
		pos cnt,0:gcopy BUF2			;screen 2にコピー
	loop
	screen n2id,gy,gx,4|2:gmode 0,gy,gx
	gcopy BUF1,(sy-gy),(sx-gx)
	buffer BUF1:buffer BUF2:buffer BUF3
	gsel n2id,1
	return
#global

screen 0,,,0
	picload dir_exe+"/sample/demo/jp6girl.bmp"

	nekkoro2 20,0					;screen 20に反時計方向に回転してみる

	gsel 0						;gselで選択
	nekkoro2 21,1					;screen 21に 時計方向に回転してみる
	redraw
stop

Dripです。

　bombさん、有難うございます。
私には機械語はさっぱりなので一体なぜ動くようになったのかわかりませんが・・
ひょっとしてbombさんはネイティブコードが読めたりしますか？凄いです。

　なたでさんの方法ではやはりかなり重いです。通常のVRAM+peek,pokeでは有り得ない程の
実行速度ですが・・扱う画像サイズが超巨大になると処理時間が気になります。
しかし非常によく考えられたアルゴリズムですね。興味深いので詳しく見てみたいと思います。

　今回はとても参考になりました。
みなさん、たくさんのご返信を有難うございました。

とっくに解決済みのスレを いつまでも ひきづりたくないのですが．．．

>すみません。1.5倍でした。

どういう理屈で言っているのか解りませんが、
直接ポインタを指定するのと 毎回取得してから指定するのでは
どう考えても 前者が速いのでは？
と言うか 大きな画像処理に比べ そんなのは 無視される時間になるのでは？

とっくに解決済みのスレを いつまでも ひきづりたくないのですが．．．

>直接ポインタを指定するのと 毎回取得してから指定するのでは
>どう考えても 前者が速いのでは？

どう考えても実行される命令の数が少ないほうが早いのでは？









ｗ

とっくに解決済みのスレを いつまでも ひきづりたくないのですが．．．

>と言うか 大きな画像処理に比べ そんなのは 無視される時間になるのでは？

どういう計算によって　実行時間が無視できる　としたのです？
一般的に m*n 時間の処理は無視できません。
無視できるのは　定数時間　のみです。

Akimさん。
No9536に対するNo11465,No11466の意見について、反論等ありませんでしょうか？
それとも自分の間違った認識を認めずにだんまりですか？

Dripです。

　HSP3掲示板管理者様、
このスレッドはスパムボットに登録されているようです。
いくらスパム記事を削除しても自動的にスパム投稿が行われ、
根本的な解決策が投じられない限り、他のビジターに迷惑をかけてしまいます。
今後スパムに埋められ、ご迷惑をおかけしないよう、このスレッドそのものの
削除をお願いしたく思います。

　また問題解決にご協力してくださった皆様、本当に有難うございました。

ではスレッド内容を丸々コピーして別スレッドで論議しましょう。

おや。まぁ。レスのついた質問を質問者自らなかったことにしてしまわれたようです。