PGETが重い
(’’ 2013/7/30(Tue) 10:37:50|NO.55973
ので調べたりして各色ごとのpgetをつくってみたんですが、
バッファオーバーフロー対策をしてたりかなりの数実行するためまだ重いです・・・
screen 21 ; レイヤー2描画用
VRAM=0 : mref VRAM,66 ; レイヤー2のVRAM
l2winW=ginfo(12) : l2winH=ginfo(13) ; 〃 のWH
l2size=l2winW*l2winH*3 ;高速化用
#define ctype PgetR(%1,%2) peek(VRAM,limit(((( abs(%1)+(l2winH-1-abs(%2))*l2winW)*3 )+2),0,l2size-2))
#define ctype PgetG(%1,%2) peek(VRAM,limit(((( abs(%1)+(l2winH-1-abs(%2))*l2winW)*3 )+1),0,l2size-1))
#define ctype PgetB(%1,%2) peek(VRAM,limit(((( abs(%1)+(l2winH-1-abs(%2))*l2winW)*3 ) ),0,l2size))
これを少し改善できませんでしょうか?
関係ないですがVRAM=0としてるのは未初期化変数の回避です
KA 2013/7/30(Tue) 12:13:16|NO.55974
多分、%1%2が座標だと思うけど limit や abs は不要だと思う。
(’’ 2013/7/30(Tue) 12:59:16|NO.55975
あ、説明忘れてました%1,%2が座標です
limitは画面外を参照するとエラーになってしまうのでそれの回避です
absは・・・なんでしたっけ・・・ 多分いりませんね
KA 2013/7/30(Tue) 14:29:03|NO.55977
>>limitは画面外を参照するとエラーになってしまうのでそれの回避です
0 <= limit() <= l2size-1
だと思うけど
0 <= %1 <= l2winW-1
0 <= %2 <= l2winH-1
の方で制限されるから不要だと思う。
上記(-1)の意味を理解出来れば、エラーの原因も分かる。
(’’ 2013/7/30(Tue) 14:44:11|NO.55978
どうすればいいんでしょう・・・
-1は幅とピクセルの誤差だと思いますが、エラーは回避できないと思います
VRAM=0 : mref VRAM,66 ; レイヤー2のVRAM
l2winW=ginfo(12) : l2winH=ginfo(13) ; 〃 のWH
l2size=l2winW*l2winH*3 ;高速化用
#define ctype PgetR(%1,%2) peek(VRAM,(%1)+(l2winH-1-(%2))*l2winW*3 +2)
#define ctype PgetG(%1,%2) peek(VRAM,(%1)+(l2winH-1-(%2))*l2winW*3 +1)
#define ctype PgetB(%1,%2) peek(VRAM,(%1)+(l2winH-1-(%2))*l2winW*3 )
mes PgetR(-10,1000)
↑でエラー
KA 2013/7/30(Tue) 15:28:42|NO.55979
>>-1は幅とピクセルの誤差だと思います
誤差ではなくて、0と言う基準位置を考慮した値です。
640×480ピクセルの起点座標は0,0で、終点座標は639、479です。
変数のバイト数は100バイトでも、各バイトの指定は0〜99です。
>>mes PgetR(-10,1000)
その数値を指定した根拠は何でしょうか。
「有り得ない数値を指定してもエラーにさせない」と言う意味なのかな?
KA 2013/7/30(Tue) 15:33:21|NO.55980
>>「有り得ない数値を指定してもエラーにさせない」と言う意味なのかな?
ごめん、そういう意図でしたね。
それなら PgetR(-10,1000) の範囲自体を制限するべきです。
(’’ 2013/7/30(Tue) 15:47:22|NO.55981
>それなら PgetR(-10,1000) の範囲自体を制限するべきです。
したいのですが、下のようにすると
#defcfunc PPgetR int _x,int _y
if _x<0|_x>l2winW1 : return 0
if _y<0|_y>l2winH1 : return 0
return peek(VRAM,_x+(l2winH1-_y)*l2winW3+2)
最初に書いたPgetRよりも重くなってしまって、速度的にきついです
peekで範囲外を取ろうとしたらエラーじゃなくて0を返してくれればやりやすいんですが・・・
(’’ 2013/7/30(Tue) 15:48:21|NO.55982
すみません速度のソースはこれです
screen 0,,,0
VRAM=0 : mref VRAM,66
l2winW=ginfo(12) : l2winH=ginfo(13)
l2winW1=l2winW-1 : l2winH1=l2winH-1
l2winW3=l2winW*3
l2size=l2winW*l2winH*3
#define ctype PgetR(%1,%2) peek(VRAM,limit((( ((%1)+(l2winH-1-(%2))*l2winW)*3 )+2),0,l2size-2))
#define ctype PgetG(%1,%2) peek(VRAM,limit((( ((%1)+(l2winH-1-(%2))*l2winW)*3 )+1),0,l2size-1))
#define ctype PgetB(%1,%2) peek(VRAM,limit((( ((%1)+(l2winH-1-(%2))*l2winW)*3 ) ),0,l2size))
#uselib "winmm.dll"
#func timegettime "timeGetTime"
#func timeBeginPeriod "timeBeginPeriod" int
#func timeEndPeriod "timeEndPeriod" int
timeBeginPeriod 1
timegettime
kako=stat
repeat 1000000 ; 10万回
;ここに命令
a=PgetR(10,10)
loop
timegettime
kako=stat-kako
pos 50,50:mes ""+kako+"ミリ秒"
stop
#defcfunc PPgetR int _x,int _y
if _x<0|_x>l2winW1 : return 0
if _y<0|_y>l2winH1 : return 0
return peek(VRAM,_x+(l2winH1-_y)*l2winW3+2)
seasalt 2013/7/30(Tue) 15:53:25|NO.55983
pgetは繰り返すと重く感じますよね。
画像のすべてのピクセルの色情報を読み取るとか、自分もやったんでわかります。
KAさんのおっしゃるように、異常な値はPgetRなどに渡さないよう、事前に弾くようにした方が良いと私も思います。
もっとも、limitとabsを省いた時点で以前の何倍か速くなってると思いますが。
seasalt 2013/7/30(Tue) 15:59:08|NO.55984
if _x<0|_x>l2winW1 : return 0
if _y<0|_y>l2winH1 : return 0
この処理をループ内でする必要がなくなるようにスクリプトを組む、という事です。
(’’ 2013/7/30(Tue) 16:09:33|NO.55985
あぁ、なるほど・・・
スプリクトは面倒になりますが速度的にはそれがベストですね
ありがとうございます。頑張ってみます
KA 2013/7/30(Tue) 16:29:04|NO.55986
>>スプリクトは面倒になりますが
3箇所に書く所を1箇所に出来るので簡単になるはずだが?
それは別としてバイナリデータとして扱うのなら、3バイト一括してRGBに
分離した方が速いような気もする。
(’’ 2013/7/30(Tue) 16:41:32|NO.55988
自分の作ってるのはマップの当たり判定をVRAMの色にしてるようなのでして、
主人公の部分を簡略化すると
jjl=-4 : jjr=5 : jju=-10 : jjd=6
gsel 21 ;当たり判定バッファ
repeat jjr-jjl
X=int(cnt+jx+jjl-mapx)
repeat jjd-jju
Y=int(cnt+jy+jju-mapy)
if (PgetR(X,Y)&32) : jdie=1
loop
loop
gsel 0
こうなってます
これだと値を制限するのがめんどくさそう・・・と思っただけです
KA 2013/7/30(Tue) 17:49:36|NO.55989
ああ、不規則に動く範囲(主人公)を背景色(専用ではない)で調べたいという意味かな。
当たり専用で単調色のマップを、もう1画面用意した方が単純かもしれない。
(赤だけで0〜255を判断するなど)
それが嫌なら、各色の最下位ビットで判断する。
(普通は0で、判定部分は1にするなど)
どちらにしても、どういう背景を考えているのかで、判定方法は色々考えられる。
(’’ 2013/7/30(Tue) 18:31:08|NO.55991
>当たり専用で単調色のマップを、もう1画面用意した方が単純かもしれない。
判定はスプライトごとに画像を描画するタイプで、元とする画像ファイルは色んな色が合ったほうが見やすいので三色使っています
>それが嫌なら、各色の最下位ビットで判断する。
上と同じ理由です
結局は速度を早くしたいので、一番の原因っぽいpgetを最初に質問しました