HSPTV!掲示板

ので調べたりして各色ごとのpgetをつくってみたんですが、
バッファオーバーフロー対策をしてたりかなりの数実行するためまだ重いです・・・

screen 21	; レイヤー2描画用

VRAM=0 : mref VRAM,66						; レイヤー2のVRAM
l2winW=ginfo(12) : l2winH=ginfo(13)			;　〃　　のＷＨ
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としてるのは未初期化変数の回避です

多分、％１％２が座標だと思うけど limit や abs は不要だと思う。

あ、説明忘れてました%1,%2が座標です

limitは画面外を参照するとエラーになってしまうのでそれの回避です
absは・・・なんでしたっけ・・・　多分いりませんね

>>limitは画面外を参照するとエラーになってしまうのでそれの回避です

0 <= limit() <= l2size-1
だと思うけど
0 <= %1 <= l2winW-1
0 <= %2 <= l2winH-1
の方で制限されるから不要だと思う。

上記(-1)の意味を理解出来れば、エラーの原因も分かる。

どうすればいいんでしょう・・・
-1は幅とピクセルの誤差だと思いますが、エラーは回避できないと思います

VRAM=0 : mref VRAM,66						; レイヤー2のVRAM

l2winW=ginfo(12) : l2winH=ginfo(13)			;　〃　　のＷＨ
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)

↑でエラー

>>-1は幅とピクセルの誤差だと思います
誤差ではなくて、０と言う基準位置を考慮した値です。
６４０×４８０ピクセルの起点座標は０，０で、終点座標は６３９、４７９です。
変数のバイト数は１００バイトでも、各バイトの指定は０〜９９です。

>>mes PgetR(-10,1000)
その数値を指定した根拠は何でしょうか。
「有り得ない数値を指定してもエラーにさせない」と言う意味なのかな？

>>「有り得ない数値を指定してもエラーにさせない」と言う意味なのかな？
ごめん、そういう意図でしたね。

それなら PgetR(-10,1000) の範囲自体を制限するべきです。

>それなら 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を返してくれればやりやすいんですが・・・

すみません速度のソースはこれです

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)

pgetは繰り返すと重く感じますよね。
画像のすべてのピクセルの色情報を読み取るとか、自分もやったんでわかります。
KAさんのおっしゃるように、異常な値はPgetRなどに渡さないよう、事前に弾くようにした方が良いと私も思います。
もっとも、limitとabsを省いた時点で以前の何倍か速くなってると思いますが。

	if _x<0|_x>l2winW1 : return 0

	if _y<0|_y>l2winH1 : return 0

この処理をループ内でする必要がなくなるようにスクリプトを組む、という事です。

あぁ、なるほど・・・
スプリクトは面倒になりますが速度的にはそれがベストですね
ありがとうございます。頑張ってみます

>>スプリクトは面倒になりますが
３箇所に書く所を１箇所に出来るので簡単になるはずだが？

それは別としてバイナリデータとして扱うのなら、３バイト一括してＲＧＢに
分離した方が速いような気もする。

自分の作ってるのはマップの当たり判定を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

こうなってます
これだと値を制限するのがめんどくさそう・・・と思っただけです

ああ、不規則に動く範囲（主人公）を背景色（専用ではない）で調べたいという意味かな。

当たり専用で単調色のマップを、もう１画面用意した方が単純かもしれない。
（赤だけで０〜２５５を判断するなど）

それが嫌なら、各色の最下位ビットで判断する。
（普通は０で、判定部分は１にするなど）

どちらにしても、どういう背景を考えているのかで、判定方法は色々考えられる。

>当たり専用で単調色のマップを、もう１画面用意した方が単純かもしれない。
判定はスプライトごとに画像を描画するタイプで、元とする画像ファイルは色んな色が合ったほうが見やすいので三色使っています
>それが嫌なら、各色の最下位ビットで判断する。
上と同じ理由です

結局は速度を早くしたいので、一番の原因っぽいpgetを最初に質問しました