HSPTV!掲示板

#include "d3m.hsp"
#define c_gtn d3timer()
#define k 1
	wait 10
	repeat 100
		w=cnt+1 : s=c_gtn : x=cnt\10*64 : y=cnt/10*20
		repeat k : await w : loop
		t=(c_gtn-s)/k
		color t*2,0,255-t*2 : boxf x,y,x+63,y+19
		color 255,255,255 : pos x,y : mes ""+w+":"+t
	loop

　上記のソースを流せば分かる通り、d3timer命令によれば、await命令の引数が多少変わった
ところで、待ち時間自体はほとんど変わらない事になります。これでは10ms精度のwait命令に
さえ劣ります。(計測上は大体15〜16ms単位で待ち時間が変動しているので)

　そもそもwait命令よりCPUパワーを使うawait命令の唯一の利点はwait命令以上の時間精度の
はずです。その時間精度でさえwait命令に劣るようでは、もはやawait命令には利用用途が
ありません。
　そうなれば、既存のawait命令を全てwait命令に置換してしまった方がプログラムの重量が
軽くなります。

　で、本題なのですが、時間精度の有利を失ったawait命令に利用価値はあるのでしょうか。
それとも、ただ私のパソコンだけがawait命令の精度を活かせていないだけなのでしょうか。
ご指導よろしくお願いします。

awaitに限らず優先度等色々関わってくると思いますが、そもそも高精度な為に起こり得る利点というのも少ない気がします。
waitよりも短い間隔でセットできたりパラメータを省略する事でCPU全開での処理が行えるという点がもっとも大きいのではないでしょうか。

　木村さんの書いていることはWindowsの問題点なので、
HSP上での改善は難しいと思われます。

　どこが優秀かとかではなく、各命令の特質を知った上で
目的に応じて使い分けることが肝要です。
そういう意味では、waitにもawaitにも存在意義があります。

　waitとawaitの最大の違いは時間計測の起点です。
ゲーム等で、速いマシンでも遅いマシンでも同じ速度で動くように
ループ内ディレイを調節したい場合、waitでは話になりません。

　HSP3では未確認ですが、BGMを流すと精度が上がるという情報もあります。

ふむ。
awaitで精度が出りゃ良いのだな？

#include "d3m.hsp"
#define c_gtn d3timer()
#define k 1

#uselib "winmm.dll"
#cfunc ctimeBeginPeriod	"timeBeginPeriod"	int		// タイマ周期(分解能)を指定(ms)
#cfunc ctimeGetTime		"timeGetTime"				// PCが起動してからの時間(ms)取得
#cfunc ctimeEndPeriod 	"timeEndPeriod"		int		// タイマ周期を変更していたら元に戻す
//	ret = ctimeBeginPeriod( 1 )  // ここのリマークを外すか外さないかで変わる

#define fwait( %1 )		fW=ctimeGetTime()+%1:while(fW>ctimeGetTime()):await 0:wend

	wait 10
	repeat 100
		w=cnt+1 : s=c_gtn : x=cnt\10*64 : y=cnt/10*20
		repeat k : fwait w : loop
		t=(c_gtn-s)/k
		color t*2,0,255-t*2 : boxf x,y,x+63,y+19
		color 255,255,255 : pos x,y : mes ""+w+":"+t
	loop

・・・・やっといて何だが、反則かな。

>>u様
　wait 0とawait 0の待ち時間を調べてみましたが、確かに連続させてみるとawaitの方が待ち
時間の総量が少なくなっていました。Windows運用上最低限のCPUパワーを除く全CPUパワーを
HSPに動員したい際にはawait命令の方が有効なようでした。御指導感謝いたします。

>>ANTARES様
>>ループ内ディレイを調節したい場合、waitでは話になりません。
　なるほど。フレーム毎のデータ処理量に波がある際にFPS等を安定させるにはawait命令しか
使えませんか。BGMの話も初耳で勉強になりました。御教授助かりました。

>>f(飲茶中)様
　これは確かに高精度のウェイトが取れますね。……しかしCPUが常時ほぼ100%消費はツラい。
ですが、こういうソースもあるのだと知る事ができて、また一つできる事の幅が増えました。
わざわざソースまで作ってくださってありがとうございます。


　で、結論ですがwait命令に切り替えるつもりだったawait命令部分は切り替えないように
します。安定したFPSが望まれるゲームソースではawait命令の方が好ましいと判断したから
です。
　回答してくださった皆様、重ね重ね感謝いたします。ありがとうございました。

　解決チェックを入れ忘れていました。失礼をば

>>木村様
もはや蛇足のような気がしますが、時間待機にWin32APIのSleepを用いれば若干ながら精度が上がったりします
ただし、HSPのメッセージ処理のためawait 0を挟まなければいけませんが
（Sleepは単体だと結構精度が悪いですがtimeBeginPeriodを使って分解能を設定すると精度がそれに合わせられる謎の仕様があります

f(飲茶中)様のスクリプトを改造させていただきました

#include "d3m.hsp"
#define c_gtn d3timer()
#define k 1

#uselib "winmm.dll"
#cfunc ctimeBeginPeriod	"timeBeginPeriod"	int		// タイマ周期(分解能)を指定(ms)
#cfunc ctimeGetTime		"timeGetTime"				// PCが起動してからの時間(ms)取得
#cfunc ctimeEndPeriod 	"timeEndPeriod"		int		// タイマ周期を変更していたら元に戻す
	ret = ctimeBeginPeriod( 1 )

#include "kernel32.as"

// ↓の値はSleepの精度が若干マシンによって変わるので適当に合わせる
#define c 0

	onexit goto *onExit_
	repeat 100
		w=cnt+1 : s=c_gtn : x=cnt\10*64 : y=cnt/10*20
		Sleep limit( w-c, 0, 100 ) : await 0
			t=(c_gtn-s)/k
		color t*2,0,255-t*2 : boxf x,y,x+63,y+19
		color 255,255,255 : pos x,y : mes ""+w+":"+t
	loop
	stop

*onExit_
	ret = ctimeEndPeriod( 1 )
	end
end

私の環境だとこれでまぁちょっとはマシな値を示してくれたりします、参考までに〜

>>えくー様
　これはすごい。確かにこれなら実用レベルのCPUパワーです。わざわざ書き込んでくださった
のに返答が遅れてしまって申し訳ありません。そして、このようなソースを提示してくださって
本当にありがとうございます。

>>ありさん
　ありさんのおかげでえくー様の書き込みが発見できた事を考えると、あまり申し上げたくは
ないのですが、やっぱり

滚出去从这个网站!!

……ですね。

　SPAMは（特に今回の場合、明らかに）人間が
書き込んでいるわけではないので、
レスしても無意味です。