HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2006
1223
Drip (投稿者削除)17停止


Drip

リンク

2006/12/23(Sat) 16:59:23|NO.4355

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



この記事に返信する


Drip

リンク

2007/1/13(Sat) 15:28:05|NO.4768

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
MSペイントのような、単純な90度単位の回転を高速に行いたかったのですが・・
HSP3では無理なのでしょうか。



As

リンク

2007/1/16(Tue) 01:19:36|NO.4833

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

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



As

リンク

2007/1/16(Tue) 01:28:01|NO.4834

なるほど。
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

リンク

2007/1/20(Sat) 03:30:32|NO.4912

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しか手がなさそうですが、これだと物凄く鈍足なんですよね;



ゆちボン

リンク

2007/1/20(Sat) 09:36:25|NO.4914

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

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

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



なたで

リンク

2007/1/20(Sat) 17:12:05|NO.4927

ぷまさまの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



Bomb

リンク

2007/1/20(Sat) 17:19:43|NO.4928

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

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



なたで

リンク

2007/1/20(Sat) 17:20:50|NO.4929

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



なたで

リンク

2007/1/20(Sat) 17:26:29|NO.4931

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


//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

リンク

2007/1/20(Sat) 23:44:43|NO.4954

Dripです。

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

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

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



Akim

リンク

2007/7/15(Sun) 23:08:23|NO.9536

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

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

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



n

リンク

2007/10/5(Fri) 16:35:57|NO.11465

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

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

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













n

リンク

2007/10/5(Fri) 16:41:17|NO.11466

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

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

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



n

リンク

2007/10/21(Sun) 16:52:15|NO.11852

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



Drip

リンク

2007/10/21(Sun) 20:34:48|NO.11853

Dripです。

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

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



n

リンク

2007/10/21(Sun) 20:55:03|NO.11854

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



n

リンク

2007/10/21(Sun) 20:56:50|NO.11855

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



ONION software Copyright 1997-2023(c) All rights reserved.