HSPTV!掲示板

タイピングゲームを作っているのですが、2.4GHzのCPU50%でFPS78あたりのキープになってしまいます。
またvbmp3.dllをつかって音楽の再生とオシロスコープを表示させ、ついでに歌詞のリアルタイムタイピング機能+オシロスコープの色変えを行なっています。
これら全てを部屋の中に立体風に表示させているので、gsquareの使いすぎで重くなってしまいます。
そこで3D描画を使えば行けるのではないかと思ったのですが、初めて手を付ける手法で、また9月の初め頃には完成しないといけない作品で、ちょっと焦ってます。

・ウィンドウは640x480
・学校の視聴覚室の背景で、大きな画面と手前にパソコンの画面がいくつかある背景。
・基本的なところを全て大きな画面のところにgsquareで合成(ちょっと立体風)
・ミス回数、正解回数(合っている回数)、フレームレートを手前のパソコンの画面にgsquareで合成
・壁にオシロスコープ、その背景をgsquareで合成
・どの合成も半透明+透明色指定、bufferで作った仮想画面に描画したものを合成。

どれも背景に合成するだけなので、文字をちょっと立体風に傾けて合成出来ればいいもので、オシロスコープも出来たらこれでやってしまいたいです。
初めてなので何一つわかりません。サンプルも見てみたのですが、やりたいことが高度すぎてわからなくなってきてしまいます。
このようなことができるソースをどなたか教えていただけないでしょうか。
もし無理なら無理と言ってください。gsquareでなんとか間に合わせます。
初心者で申し訳ありませんが、どうぞよろしくお願いします。

hgimg3を使うのにgsquare・・・？
とりあえずgsquareは重いので、普通の短形コピーを使えるように仕様変更してできるだけhgrotateにしてみて下さい

>>やりたいことが高度すぎてわからなくなってきてしまいます。

「重い」というだけなら、パソコンの性能を上げましょう。

時間が無いのに無理して方針転換しても、中途半端で終わる可能性があります。
それなら完成している現状のスクリプトを、効率化出来ないか考えた方が得策です。

今のグラフィックをそのまま活かす、ということなら、
（’’さんの言うようにgsquareをhgrotateに置き換えるのが
手っ取り早いのですが、奥行きのある表示をしたいのであれば
hgrotateの回転だけでは表現できないかも知れません。

３Ｄのプレートモデルにグラフィックをテクスチャとして貼って
表示するのが近道かも。

ただし、hgimg3の基本的なお作法をひととおり勉強しないといけないので、
それなりに労力と時間はかかります。
こちらのいなえさんの講座で勉強してみてわからなければ、
今のソースをブラッシュアップしたほうがよいかも。
http://www.geocities.jp/inaeggmon/index.html

みなさま早い回答をありがとうございます。

("様
>>hgimg3を使うのにgsquare・・・？
というのもhgimg3を使わずに今、gsquareを使って表示させています。
外形だけ遠近法を再現して背景に合成しているのですが、それでは遅くなってしまうので、今回hgimg3を使おうと思いました。

>>とりあえずgsquareは重いので、普通の短形コピーを使えるように仕様変更してできるだけhgrotateにしてみて下さい
hgrotateは二次元の回転の命令のようで、今回やろうとしているのは奥行き感なのでこれでは再現できないみたいです…。

KA様
>>「重い」というだけなら、パソコンの性能を上げましょう。
言い忘れたのですが、文化祭で発表しようとしているのですが、使えるPCの情報が入っていないので、どんなPCでもとりあえず動くぞっていう物が作りたいのです。

ZAP様
>>３Ｄのプレートモデルにグラフィックをテクスチャとして貼って
>>表示するのが近道かも。
サンプルを見たりヘルプブラウザでhgimg3を検索して見ていてその点も思いました。
紹介していただいたホームページを熟読すればわかることなのかもしれませんが、
テクスチャとしてbufferで初期化した仮想画面を貼り付けることはできるのでしょうか？

それにしてもFPS78ってのはそこまで必要なのでしょうか。

例えばFPS60にして、その分描画時間を確保する、いう選択肢も
あると思いますが。

あと、今作っているゲームのイメージ画像があれば、もっと具体的な意見が
もらえる（かも）しれません。

＞テクスチャとしてbufferで初期化した仮想画面を貼り付けることはできるのでしょうか？

できなくはないですが、それだとテクスチャとして貼り付ける前のbufferに対しては
通常の命令で描画を行うことになるので、前と同じようにgsquareを使うのであれば、
そこで描画コストがかかり、速度的にhgimg3を使うメリットがあまりないです。

基本は画像ファイルから登録した机だの壁だのパソコンだのといった個々のオブジェクトを
角度や奥行き、サイズを指定してhgimg3の画面に直接貼り付けていくことを繰り返して
画面を作っていくことになります。

それでも速度的には充分速いと思います。

>>それにしてもFPS78ってのはそこまで必要なのでしょうか。
>>例えばFPS60にして、その分描画時間を確保する、いう選択肢も
>>あると思いますが。
先ほどKA様への返信でも書きましたが、どんなPCでも動く物を作りたいのです。
たとえばこのPCのCPUはIntel Pentium B970 @ 2.30GHzで、現在FPS78前後なのですが、
先日学校にあった古いXPのPCでPentium4の場合、FPSが62ぎりぎりのところでした。
FPS60に設定したとしても古いPCだと間に合わない可能性も出てくるのでそこまで重要性はないかと…；
ただ性能が有り余っているPCに無理に仕事させないようにするにはしておいたほうがよさそうですね…。


先ほど
テクスチャとしてbufferで初期化した仮想画面を貼り付けることはできるのでしょうか？
という事を書いたのですが、出来たみたいです…；
ただ背景の透過の方法がわからないので教えていただけると助かります；

>>基本は画像ファイルから登録した机だの壁だのパソコンだのといった個々のオブジェクトを
>>角度や奥行き、サイズを指定してhgimg3の画面に直接貼り付けていくことを繰り返して
>>画面を作っていくことになります。
それなのですが、背景をまずいちばん奥に表示させ、その全面にgsquareで合成する同様に
3Dのプレートモデル(合ってるかな…；)を回転させていい具合に表示させたいです。
つまり部屋のパーツを全てオブジェクトを配置していくのではなく、ただ画面を合成したいだけです。
イメージなんですが、
https://docs.google.com/file/d/0BxOw0FGZSRnfUkRiS2xJRGZKRHM/edit
こちらに載せたのが現在の画面です。

> また9月の初め頃には完成しないといけない作品で、ちょっと焦ってます。

残り1.5ヶ月ですか。
締め切りが近いので、今から大きな仕様変更をするのはお勧めしません。
無理にやってしまうと作り込みや調整、デバッグができなくなると思って下さい。つまり完成が間に合いません。

ちなみにこれは経験則ですが、ソフトの不具合発見やPC故障は締め切り間際や忙しい時に限って出ます。ｗ


ということで今からは、バグの抽出とデバッグに注力することをおすすめします。

まず既に「処理が重い」バグが発生していますのでこれに対応します。
・一番重くなっている原因を探す。
　どの処理が一番重くなっているか、コメントアウトなどを使ってランク付けして下さい。
　重い物上位から対策を考えていくといいです。
・gsquareが多すぎるのが原因だった場合…gsquareの数を減らす。
　・見栄えに重要な影響がないものは消す。シンプルな最小限の構成にする。
　・1つに纏められるものは1つにまとめる。
　　相対位置が変わらないものどうしなど。テクスチャ画像を工夫して何とかならないか考えてみる。
・gsquareで使用しているテクスチャ画像の解像度を落としてみる。（意味ない？）
・オシロスコープをやめる。
・FPS値を30にする。

まずは「完成品」を作ることよりも、締め切りまでに「プレイできる作品」を用意出来ることが重要です。
実装するとどうしても重くなってしまうなど回避できない不具合がる機能は、今回の実装を見送りましょう。


また、ある程度ちゃんと動くようになったら、次は出来るだけ多くの人にテストプレイしてもらって下さい。
バグ以外にも新鮮な意見がボロボロでてくるのでそれに対応しているうちに時間なくなると思います。
1ヶ月なんてあっという間ですよ。



> このようなことができるソースをどなたか教えていただけないでしょうか。

いまひとつよくわからないけど、d3moduleで作るのもいいかなとお思いました。
速度面での改善は見込めないんでやっぱりhgimg3なのかな。

> イメージなんですが、
> https://docs.google.com/file/d/0BxOw0FGZSRnfUkRiS2xJRGZKRHM/edit
> こちらに載せたのが現在の画面です。

gsquareが5個ですか。これで使いすぎってことは無いと思うんですが…？

GENKI様ありがとうございます。

>>・gsquareが多すぎるのが原因だった場合…gsquareの数を減らす。
>>　・見栄えに重要な影響がないものは消す。シンプルな最小限の構成にする。
>>　・1つに纏められるものは1つにまとめる。
一回のgsquareでは見づらいので、透明度128のgsquareを重ねて2度表示させてます。
さすがに使いすぎですかね…；
なので
>>gsquareが5個ですか。これで使いすぎってことは無いと思うんですが…？
というのも、実際にプレー中使われるのは、
・キーを押されたか問題が変わった場合→gsquareが11回
・それ以外→gsquareが7回
です。多すぎますねやめます；

>>・gsquareで使用しているテクスチャ画像の解像度を落としてみる。（意味ない？）
試験的に行なってみたところ、メインの画面の解像度が800x600の場合より2880x2160(4Kサイズの4:3バージョン)のほうが格段に重く、400x300はあまり影響がありませんでした。

>>・オシロスコープをやめる。
ここだけは絶対に譲れません(

>>・FPS値を30にする。
FPSを30にしても、描画中にキーを押して離されてしまっては判定のしようがありません…。

>>まずは「完成品」を作ることよりも、締め切りまでに「プレイできる作品」を用意出来ることが重要です。
>>実装するとどうしても重くなってしまうなど回避できない不具合がる機能は、今回の実装を見送りましょう。
そうですね…。できるところまで頑張ってみて、無理なところは諦めることにします。

すみません、画面表示とは関係ない部分で気になったのですが。

仕様を読んだところ、このソフトは走らせるＰＣの速度に応じて、
１秒間に画面を書き換える回数が変わるようですが、

その場合、キー入力はどうなるのですか？
キー入力や判定処理が画面の書き換えと同じメインループに組み込まれていて、
画面の書き換え回数＝キー入力判定回数なのだとすれば、
FPSが60の環境だと、秒間に60回のキー判定が、
FPSが78の環境だと、秒間に78回のキー判定が行われるのでしょうか？

それだと、同じプレイヤーが同じようにプレイしても
環境によって結果に差がでませんか？

もしそうだとすれば、自分はむしろ、FPSは60なりに固定して、
キー入力のタイミングはＰＣの性能にかかわらず一定とし、
そのぶん他の処理に時間を取れるようなゲームデザインにしたほうが
良いと思うのですが、どうでしょうか。

＞それなのですが、背景をまずいちばん奥に表示させ、その全面にgsquareで合成する同様に
＞3Dのプレートモデル(合ってるかな…；)を回転させていい具合に表示させたいです。
＞つまり部屋のパーツを全てオブジェクトを配置していくのではなく、ただ画面を合成したいだけです。

つまり、
１）視聴覚室の背景の１枚絵を表示
２）正面スクリーンに、「文字を書いたスクリーン」の画像を重ねて表示
３）側壁にオシロスコープを重ねて表示
４）個々のＰＣ画面を重ねて表示
という手順でしょうか

２、３、４の内容をそれぞれ３Ｄのプレートオブジェクトとして、
描画する文字はbufferのほうで処理してからテクスチャとして貼り、
背景の前にちょうど重なって見える角度と大きさで置く、という流れで出来ると思います。

ZAP様、
>>FPSが60の環境だと、秒間に60回のキー判定が、
>>FPSが78の環境だと、秒間に78回のキー判定が行われるのでしょうか？
その通りです。厳密にはFPS60の場合は秒間に60回awaitが含まれます。
このawaitの瞬間にキーが押されていれば、gosubルーチンが作動する仕組みです。

>>それだと、同じプレイヤーが同じようにプレイしても
>>環境によって結果に差がでませんか？
>>もしそうだとすれば、自分はむしろ、FPSは60なりに固定して、
>>キー入力のタイミングはＰＣの性能にかかわらず一定とし、
>>そのぶん他の処理に時間を取れるようなゲームデザインにしたほうが
>>良いと思うのですが、どうでしょうか。
ゲームデザイン的にはそのほうがいいかもしれません。
ただ今回は文化祭で発表するプログラムで環境には依存されないのでこのような手法をとっています。
もし配布するような物にするときは、そのような手法をとらせていただきたいと思います。

FPSは上限60と決めておき、それ以上になるならばプログラムを待機、
それ以下では描画処理等をスキップするなどの手法がいいかと。

>>２、３、４の内容をそれぞれ３Ｄのプレートオブジェクトとして、
>>描画する文字はbufferのほうで処理してからテクスチャとして貼り、
>>背景の前にちょうど重なって見える角度と大きさで置く、という流れで出来ると思います。
ZAP様ありがとうございます。
もう夜も遅いので、またじっくりプログラミングすることにします。

> ・キーを押されたか問題が変わった場合→gsquareが11回
> ・それ以外→gsquareが7回

もしかして実際に表示するウィンドウ内で、プロジェクター・スクリーンの中の幾つもの表示をgsquareで作っていませんか？
buffer内でプロジェクター・スクリーンをgcopyなどで作成してしまってから、出来たものをgsquare１回すればいいのではないでしょうか？


> >>・FPS値を30にする。
> FPSを30にしても、描画中にキーを押して離されてしまっては判定のしようがありません…。

タイピングゲームはそういった問題があるので、HSPのサンプルにもある通りgetkeyではなくonkey使う方法が良いようです。
キーを押された瞬間に特定のサブルーチンにジャンプする方法で、イベントドリブンとかイベント駆動方式とか言われる方法で、あんまり馴染みはないかもしれません。
まずはサンプルを眺めたりいじったりしてみて下さい。（あまりに難しいようなら見送りましょう。^ ^;）

onkeyを使った方法ならFPS値は気にしなくて良くなります。



ところで、、、
手前のPC3台のディスプレイ内はgsquareで歪めた効果がそれほど大きくないので、思い切って普通にMESで直接描いてしまっていいかもしれません。
リアルさはなくなりますが、変形がなくなってジャギも軽減できるので逆に見やすくていいかも。…と考えてしまうのも手です。w

check様、ありがとうございます。
>>FPSは上限60と決めておき、それ以上になるならばプログラムを待機、
>>それ以下では描画処理等をスキップするなどの手法がいいかと。
FPSの維持方法…ありがとうございます。
頑張って組み込んでみます。


…皆さん夜遅くまで本当にありがとうございます。

GENKI様、
>>もしかして実際に表示するウィンドウ内で、プロジェクター・スクリーンの中の幾つもの表示をgsquareで作っていませんか？
>>buffer内でプロジェクター・スクリーンをgcopyなどで作成してしまってから、出来たものをgsquare１回すればいいのではないでしょうか？
buffer内でプロジェクター・スクリーンの画面は全て作ってあります。
ただし、それを1回のgsquareで合成するとアンチエイリアスのグレーの部分を拾ってしまって見にくくなるので、ちょっとだけ範囲をずらしたものをもう一度上から半透明で合成して、合計で2回gsquareを使っています。
手前のコンピュータ画面も同様の手法ですが、オシロスコープだけは、背景、左要素、右要素の3回を半透明で合成しています。

>>タイピングゲームはそういった問題があるので、HSPのサンプルにもある通りgetkeyではなくonkey使う方法が良いようです。
既にonkey gosubで組んでいますが、描画中の判定は無理です。

mode=1 ;何フレーム開けてawaitを入れるか。0だとエラー
x=0
frame=0
onkey gosub *key

*main
	color 255*gettime(7)/1000,255*gettime(7)/1000,255*gettime(7)/1000
	boxf
	pos 0,0
	color 0,0,0
	mes x
	if frame\mode=0:await 1
	frame++
	goto *main
	
*key
	x++
	return

これをやるとわかるのですが、modeの値を増やしてawaitの数を減らすととっても反応が鈍くなります。(onkeyの精度がawaitに依存する…？)
描画中は判定できないので、FPSというよりは性能を気にしないとだめですね…。

>>手前のPC3台のディスプレイ内はgsquareで歪めた効果がそれほど大きくないので、思い切って普通にMESで直接描いてしまっていいかもしれません。
確かに言われてみれば…歪みが少ないですね…。
正解回数はリアルさがかなりなくなりますけど、FPSとミス回数はなんとか行けそうな気がします。
アドバイスありがとうございます。

予想が外れてしまいましたか。失礼しました。

反応が鈍くなる…というのはよくわかりませんでした。
体感の問題で感じ方に個人差があるのかも？d3getfpsとか何かでもう少し目に見える形で確認出来れば…。


> if frame\mode=0:await 1

むう、ところでこれってmodeがある値以上になるとawait効かなくなりますね。
awaitの計測誤差の影響かな…？


> 描画中は判定できないので、FPSというよりは性能を気にしないとだめですね…。

まず描画と判定は切り離して考えて下さい。
メインループ内では判定結果を描画することに専念して下さい。
結果の判定は、この場合だと*key内で行うといいでしょう。

>(onkeyの精度がawaitに依存する…？)
stopやawait等でOS側にタスクを移さないとonkeyの割り込みは発生しない
適当にawait 0を散りばめれば取りこぼし難くは出来る(await 16で60固定とかは出来ないけどon系使ってるからそのそも無理だが)

on系を使ってる場合は await 固定値 だけでのフレーム管理は無理
await 16としててもキーを押されたらウェイト時間が残ってても抜ける
ので、時間でawait等の時間待ちを毎フレーム計算する必要がある

パソコン自体の色数を、８ｂｉｔや１６ｂｉｔに落とせば、多少は良くなるかも。

onkey割り込みを使っているという前提は全く想定していませんでした。

ゲームなのでメインループの中で入力チェック、判定処理を行っているものとばかり。

しかし、60FPSとして、１フレーム＝16.666...ミリ秒

この１フレームの間に「キー入力→離す」という一連の操作が行われ、
入力を取りこぼす、なんてことがそうそうあり得るのでしょうか？

そもそもキー入力というのは、OS側に何らかのバッファがあって、OS側がアイドルの時に
その入力バッファを読みに行く、そこまでの間に入力されていれば検知されるものだと
思っていたのですが、違うのでしょうか？

・・・リアルタイムで画像加工するのに時間がかかるというなら
あらかじめ加工した画像を用意すればいいじゃない。
時間がないなら尚の事、簡単に出来る処理にしないと間に合わんぞ。

FPSが７８とか６０あるんならON系使わなくていいんじゃないの？
その一フレームの間にボタンを押して離して判定されないようにするのはかなり難しいよ。
話を聞いた限りじゃ普通にメインループでkey判定して問題なさそうだけど。
その方が多分反応に関しては問題なくなると思う。

みなさまありがとうございます。

GENKI様、
>>体感の問題で感じ方に個人差があるのかも？d3getfpsとか何かでもう少し目に見える形で確認出来れば…。
ちょっと組み方がいまいちでわかりづらかったと思います。すみません。
描画中にonkey判定が入ってもawaitに依存してしまうことがわかってもらえればいいのですが…。
onkeyで判定が入った直後にiparamでキーを取得していますが、描画に時間がかかると押したはずが実は描画中で、
次のキーを押した時に先ほどのonkeyが作動して合っているキーを押してもスルーされてしまうということが起きます。
これを防ぎたいです。

>>メインループ内では判定結果を描画することに専念して下さい。
そうですね…。ループの中の余分が多すぎかもしれません。ありがとうございます。


暇人様、
>>stopやawait等でOS側にタスクを移さないとonkeyの割り込みは発生しない
なんと…その事実を知りませんでした。

>>await 16としててもキーを押されたらウェイト時間が残ってても抜ける
>>ので、時間でawait等の時間待ちを毎フレーム計算する必要がある
実測的なFPSと算出式のFPS(1フレームあたりのmsで瞬間FPSを算出)を組んでいるので、
それを応用すれば出来そうです。ありがとうございます。


KA様、
>>パソコン自体の色数を、８ｂｉｔや１６ｂｉｔに落とせば、多少は良くなるかも。
そんな荒業が…！？ちょっと考えてみます。ありがとうございます。


ZAP様、
>>ゲームなのでメインループの中で入力チェック、判定処理を行っているものとばかり。
タイピングには打ち方がいろいろあり、たとえば「ち」でもTIとCHIいうようにあります。
それをメインループの中で全て行おうとすると無理があるので(IFの使いすぎ)、キーを押した場合のみにしています。

>>しかし、60FPSとして、１フレーム＝16.666...ミリ秒
>>この１フレームの間に「キー入力→離す」という一連の操作が行われ、
>>入力を取りこぼす、なんてことがそうそうあり得るのでしょうか？
実際に60だと取りこぼす心配はありません。
ただ学校にPentium4というCPUを搭載した古いパソコンがあり、
CPUフル稼働で60FPSが限度、そのときのこのパソコンでのFPSが100に近い値でした。
今そのパソコンでテストが出来ないのでわかりませんが、FPS40くらいになってしまうと取りこぼしが多いので、
そこをなんとかして軽くしたいと思っています。

>>そもそもキー入力というのは、OS側に何らかのバッファがあって、OS側がアイドルの時に
>>その入力バッファを読みに行く、そこまでの間に入力されていれば検知されるものだと
>>思っていたのですが、違うのでしょうか？
私はそれを全く知らなかったのですが、実際にはそのようですね…。
ただ判定は、それを検知したあとにどのキーかを取得するので、描画中に2つ連続でキーを押すと、前者のキーは取得できないみたいです…。


f(VPro中)様、
>>・・・リアルタイムで画像加工するのに時間がかかるというなら
>>あらかじめ加工した画像を用意すればいいじゃない。
遠近法で書かれた文字をすべて画像で用意して、それを状況に合わせて貼り付けていくのは無理がありそうです…。
サンプルのタイピングゲームでは画面上のアルファベット通りに入力すればいいですが、
今作っているのはそれ以外の打ち方にも対応するので難しそうです。

123様、
>>FPSが７８とか６０あるんならON系使わなくていいんじゃないの？
>>その一フレームの間にボタンを押して離して判定されないようにするのはかなり難しいよ。
>>話を聞いた限りじゃ普通にメインループでkey判定して問題なさそうだけど。
>>その方が多分反応に関しては問題なくなると思う。
onkeyを使わないとなるとgetkeyを大量に並べる方法でしょうか…？
反応は良くなりそうですが、判定がその分きつくなりそうな気がしてきます。
でも方法的には一番確実な方法だと思うので、検討します。ありがとうございます。

>>onkeyを使わないとなるとgetkeyを大量に並べる方法でしょうか…？

自分が前にタイピングゲーム作ったときは適当に関数つくって判定してました。

>>今そのパソコンでテストが出来ないのでわかりませんが、FPS40くらいになってしまうと取りこぼしが多いので

onkey取りこぼすとなると反応の問題はその辺ですね。wait系が入らないとか？
基本ON系は流れをぶった切ってそこに飛ぶので、意地でも取りこぼさないはず？

あとonkeyをoffにしてる区間とかあったらよく調べてみるといいと思う。

とりあえず基本的な使い方をまとめてみました。

#include "hgimg3.as"
#const size 40.0
#const half size/2.0

title "内側に向いた板モデルを回転させるsample"

hgini

clscolor 0xccccff

// add系の命令で Objectを作成
addsplate hm_pal,0,size,size,0
setcolor ,255,255
addbox hm_handle,1,1

// regobj と setpos setang 等でObjectを登録して位置と角度を指定。objchild で オブジェクトのグループ化
regobj ho_handle,hm_handle,OBJ_HIDE

reg 0,0,-half,0,0,0
reg 0,0,half/3,m_pi,0,0

reg 0,-half,0,m_pi/2,0,0
reg 0,half,0,-m_pi/2,0,0
reg -half,0,0,0,m_pi/2,0
reg half,0,0,0,-m_pi/2,0

// カメラと光源を設定して
cammode CAM_MODE_Normal
setpos HGOBJ_CAMERA ,,30,-10
setang  HGOBJ_CAMERA,m_pi/10*5

setpos HGOBJ_LIGHT ,,30,10
setang HGOBJ_LIGHT,m_pi/3

setang ho_handle,0,0,1.95

*@
// addang , addpos 等でObject移動や、角度の移行を行う。
addang ho_handle,,,0.01
// hgdraw で描画 : hgsync で表示と ウエイトを行う。
hgdraw:hgsync 30
goto*@b


#deffunc reg double px_ , double py_ , double pz_ , double ax_ , double ay_ , double az_
	regobj ho_pal.total,hm_pal
	setpos ho_pal.total,px_,py_,pz_
	setang ho_pal.total,ax_,ay_,az_
	objchild ho_handle,ho_pal.total
	total++
	return

123様、
>>自分が前にタイピングゲーム作ったときは適当に関数つくって判定してました。
どのような関数でしょうか？
私は今回、getkeyのリファレンスにあったキーコード(文字コード？)を取得するスクリプトを使っています。

>>onkey取りこぼすとなると反応の問題はその辺ですね。wait系が入らないとか？
>>基本ON系は流れをぶった切ってそこに飛ぶので、意地でも取りこぼさないはず？
毎フレームにawait 0を入れています。
描画中はawaitが無いので、描画し終わってからawaitが入る形になります。
そこで初めてキーコードを取得しています。

>>あとonkeyをoffにしてる区間とかあったらよく調べてみるといいと思う。
onkeyをoffにしているのは事前の設定画面やキー判定中ですね…。描画のみのメインループの中ではonkeyは常に作動しています。

ツノン様、わかりやすいサンプルをありがとうございます。

みなさまのアドバイスを参考にして、いい作品を作りたいと思います。
たくさんのアドバイスをありがとうございました。

結局hgimg3を使うか分からないけど
スクリーン上の座標を指定すれば3D上にaddplateを配置するモジュールを作ってみた
NO.55884の画像を640*480の部分を切り出して座標を調整してるから
ゲームで使ってる背景画像をhspdx.bmpの代わり読み込めば3Dでやった場合の感じが分かるかな

#include "hgimg3.as"

//必ず#include "hgimg3.as"の後に配置する
#module "mod_addplateEx"

//colorを24ビット数値で指定できるマクロ
//color RGB($123456) //これでRGB指定
#define global ctype RGB(%1=0)  ((%1)>>16)&$ff , ((%1)>>8)&$ff , (%1)&$ff


//[---モジュールの初期化---]
//plateEx_init
//返り値refdvalにスクリーン座標系から3D座標系に変換する実数値が返る
//refdval*スクリーン座標*カメラからの距離で2Dから3Dに出来る
#deffunc plateEx_init
	getefx HGOBJ_CAMERA,FOV,NearZ,FarZ
	whsx=0.5*ginfo_winx
	whsy=0.5*ginfo_winy
	tc=sin(0.5*FOV)/cos(0.5*FOV)/whsy
	_msx_=0.0
	_msy_=0.0
	_sizz_=0.0
return tc


//[---addplateをスクリーン座標とサイズやスクリーン座標上の傾きに合わせてモデルを作りオブジェクトを3D上に配置---]
//addplateEx_AddObj %1,%2,%3,%4,%5,%6,%7,%8,%9,%10,%11,%12,%13,%14
// %1  : mid	= 作成されたモデルIDが代入される変数名
// %2  : mode	= 0=透明色抜きなし / 1=透明色抜きあり
// %3  : x1		= テクスチャの左上X座標
// %4  : y1		= テクスチャの左上Y座標
// %5  : x2		= テクスチャの右下X座標
// %6  : y2		= テクスチャの右下Y座標
// %7  : texid	= テクスチャID指定（%1〜%7までは省略不可）
// %8  : ssx	= スクリーン座標で基本モデル横サイズ指定(省略時テクスチャの指定からサイズを取得)[sluy,sruyの指定が傾いてる場合縦横の比率だけ利用させる]
// %9  : ssy	= スクリーン座標で基本モデル縦サイズ指定
// %10 : ssz	= カメラからの基本距離（sluy,sruyの指定が傾いてる場合は傾いてる奥行の半分をsszに足されて配置される）
// %11 : slux	= 配置するスクリーンX座標左上(省略時はカレントポジションが使われる)[sluy,sruyの指定が傾いてる場合はslux,sruxと傾きの奥行からモデルの横サイズが決められる]
// %12 : sluy	= 配置するスクリーンY座標左上
// %13 : srux	= 配置するスクリーンX座標右上(省略時は傾き無しとして実行)[右下じゃなく右上なので注意]
// %14 : sruy	= 配置するスクリーンY座標右上
//返り値statに作成したオブジェクトのIDが返る
#define global addplateEx_AddObj(%1,%2,%3,%4,%5,%6,%7,%8=$80000000,%9=$80000000,%10=50.0,%11=$80000000,%12=$80000000,%13=$80000000,%14=$80000000) _addplateEx_AddObj %1,%2,%3,%4,%5,%6,%7,%8,%9,%10,%11,%12,%13,%14 
#deffunc _addplateEx_AddObj var mid,int mode,double x1,double y1,double x2,double y2,int texid,double ssx,double ssy,double ssz,double slux,double sluy ,double srux,double sruy

	if  ssx=$80000000 {_ssx=x2-x1}else{_ssx=ssx}
	if  ssy=$80000000 {_ssy=y2-y1}else{_ssy=ssy}

	_slux=-whsx
	if slux = $80000000 {_slux+ginfo_cx}else{_slux+slux}
	_sluy=-whsy
	if sluy = $80000000 {_sluy+ginfo_cy}else{_sluy+sluy}
	_srux=-whsx
	if srux = $80000000 {_srux+_ssx}else{_srux+srux}
	_sruy=-whsy
	if sruy = $80000000 {_sruy=_sluy}else{_sruy+sruy}

	getpos HGOBJ_CAMERA,cpx,cpy,cpz
	tcz=tc*ssz
	if _sluy = _sruy {
		_msx=_ssx*tcz
		_msy=_ssy*tcz
		sizz=0.0
		opx=_slux*tcz+_msx*0.5
		opy=_sluy*tcz+_msy*0.5
		r=0.0

	}else{
		xys=_ssy/_ssx
		dy=_sluy*tc 
		uy=_sruy*tc
		if absf(dy)>absf(uy) {
			if absf(_sluy) < 0.5 {_sluy=0.5:dy=_sluy*tc}
			dy*ssz
			if uy ! 0.0 {zy=dy/uy}else{zy=dy/(tc*0.01)}
			sizx=(_srux*tc*zy-_slux*tcz)
			sizz=(zy-ssz)
			_msx=sqrt(sizx*sizx+sizz*sizz)
			rr=atan((_sruy-_sluy),(_srux-_slux))
			_msy=((_srux-_slux)/cos(rr))*tcz*xys
			r=atan(sizz,sizx)
			opx=_slux*tcz+_msx*0.5*cos(r)
			opy=_sluy*tcz+_msy*0.5
		}else{
			if absf(_sruy) < 0.5 {_sruy=0.5:uy=_sruy*tc }
			uy*ssz
			if dy ! 0.0 {zy=uy/dy}else{zy=uy/(tc*0.01)}
			sizx=(_srux*tcz-_slux*tc*zy)
			sizz=(zy-ssz)
			_msx=sqrt(sizx*sizx+sizz*sizz)
			rr=atan((_sluy-_sruy),(_srux-_slux))
			_msy=((_srux-_slux)/cos(rr))*tcz*xys
			r=-atan(sizz,sizx)
			opx=_srux*tcz-_msx*0.5*cos(r)
			opy=_sruy*tcz+_msy*0.5
		
		}
	}
	opz=-ssz-sizz/2
	addplate mid,mode,_msx,_msy,x1,y1,x2,y2,texid
	_msx_(mid)=_msx
	_msy_(mid)=_msy
	_sizz_(mid)=sizz
	regobj oid,mid
	setang oid,0.0,r,0.0

	setpos oid,opx+cpx,opy+cpy,opz+cpz
	
return oid

//[---addplateEx_AddObjで作られたモデルのサイズを取得---]
//GetModelSizeX(モデルID)
//モデルIDを指定してaddplateEx_AddObjで作られたモデルのサイズを取得する
#defcfunc GetModelSizeX int id
return _msx_(id)

#defcfunc GetModelSizeY int id
return _msy_(id)

//これはサイズと言うよりY軸が傾いてる時の奥行
#defcfunc GetModelSizeZ int id
return _sizz_(id)

//[---スクリーン座標をワールド座標に変換---]
//sptwp wpx, wpy, wpz, sx, sy, cdz
// wpx = 3DX座標を取得
// wpy = 3DY座標を取得
// wpz = 3DZ座標を取得
// sx  = スクリーンX座標指定
// sy  = スクリーンY座標指定
// cdz = カメラからの距離を3D座標系で指定
//カメラの移動回転に対応
#deffunc sptwp var wpx,var wpy,var wpz,double sx,double sy,double cdz
	getpos HGOBJ_CAMERA,cpx,cpy,cpz
	getang HGOBJ_CAMERA,crx,cry,crz
	fvset fv,crx,-cry,crz
	fvdir fv,tc*sx*cdz,tc*sy*cdz,-cdz
	wpx=fv+cpx
	wpy=fv(1)+cpy
	wpz=fv(2)+cpz
return
#global


hgini

//モジュール初期化(必ずhginiの後に実行する事)
plateEx_init
tc=refdval


hgsetreq SYSREQ_COLORKEY,$0	//テクスチャ読み込み時の透明色に黒（0）を指定

texload dir_exe+"\\sample\\hspdx\\hspdx.bmp"	//背景用の画像をテクスチャ化
bgtex_id=stat

dbg_f = 1	//デバッグ用フラグ（1にするとテクスチャにするバッファをscreenで作り表示する）	

hsptex_id=1
if dbg_f {screen hsptex_id,512,512,0,ginfo_wx2,ginfo_wy1}else{buffer hsptex_id,512,512}

color 0,255
boxf	//分かりやすいように緑の枠を造るために一度塗りつぶし

settex 512,512,0	//一度テクスチャ化してIDを取得しておく
tex_id=stat

gsel 0,1

//使用テクスチャ範囲
dim uv,4,5
uv(0,0)=0,0, 470,400
uv(0,1)=0,410, 100,510
uv(0,2)=110,410, 170,470
uv(0,3)=180,410, 240,470
uv(0,4)=250,410, 310,470

crdat=0,$006060,0,0,0	//クリア色設定

setpos HGOBJ_CAMERA,0,0,50
setang HGOBJ_CAMERA,0.0,0.0,0.0

addplateEx_AddObj mid,1,uv(0,0),uv(1,0),uv(2,0),uv(3,0),tex_id,450,350,100,-25,-30,426,37	//メイン
oid=stat
addplateEx_AddObj mid(1),0,uv(0,1),uv(1,1),uv(2,1),uv(3,1),tex_id,120,250,50,518,37,635,-23 //波線	これだけ背景を透明にしないでみる
oid(1)=stat
addplateEx_AddObj mid(2),1,uv(0,2),uv(1,2),uv(2,2),uv(3,2),tex_id,50,40,70,62,287,111,287	//FPS
oid(2)=stat
addplateEx_AddObj mid(3),1,uv(0,3),uv(1,3),uv(2,3),uv(3,3),tex_id,50,40,30,107,311,180,309	//ミス
oid(3)=stat
addplateEx_AddObj mid(4),1,uv(0,4),uv(1,4),uv(2,4),uv(3,4),tex_id,50,50,50,470,295,518,292	//正解
oid(4)=stat

clstex bgtex_id	//背景用のテクスチャを背景クリア用テクスチャに指定(hgdraw実行時に自動でこのテクスチャが背景に貼られる)


*main

gsel hsptex_id

if dbg_f {redraw 0}

repeat 5
	color RGB(crdat(cnt))	//テクスチャ補間で背景の色の影響を受けるので文字エリアは黒でクリア
	boxf uv(0,cnt)+3,uv(1,cnt)+3,uv(2,cnt)-3,uv(3,cnt)-3	//枠内を黒(指定透明色)でクリア
	if cnt=0 {
		color 50,50,50
		font "ＭＳ 明朝",30
		pos uv(0,cnt)+25,uv(1,cnt)+30
		mes strf("%1d:%2d:%3d",gettime(5),gettime(6),gettime(7))
		pos uv(0,cnt)+25,uv(1,cnt)+130
		mes "メインスクリーン文字表示"
		font "ＭＳ 明朝",16
		mes "あいうえおかきくけこ"
	}else{
		if cnt=1 {
			lpx=uv(0,cnt)+3
			lpy=uv(1,cnt)+50
			pos lpx,lpy
			repeat 23
				color rnd(255),rnd(255),rnd(255)
				sinr=sin(0.5*rnd(180))
				line cnt*4+lpx,sin(sinr)*10.0*(0.1*rnd(25)+1)+lpy
			loop
		}else{
			if cnt=2 {
				color 10,10,10
				font "ＭＳ 明朝",24
				pos uv(0,cnt)+3,uv(1,cnt)+3
				mes "FPS"
				font "ＭＳ 明朝",34
				pos uv(0,cnt)+10,uv(1,cnt)+24
				mes fps
			}else{
				if cnt=3 {
					color 10,10,10
					font "ＭＳ 明朝",14
					pos uv(0,cnt)+3,uv(1,cnt)+10
					mes "ミス回数"
					font "ＭＳ 明朝",26
					pos uv(0,cnt)+5,uv(1,cnt)+20
					mes fps_cnt_bak
				}else{
					if cnt=4 {
						color 10,10,10
						font "ＭＳ 明朝",14
						pos uv(0,cnt)+3,uv(1,cnt)+5
						mes "正解回数"
						font "ＭＳ 明朝",26
						pos uv(0,cnt)+5,uv(1,cnt)+20
						mes fps_cnt\10000
					}
				}
			}
		}
	}

loop


if dbg_f {redraw 1}

settex 512,512,0,tex_id	//テクスチャ更新

gsel 0

hgdraw
hgsync 15
hggettime tim,0
mtim=tim/1000
fps_cnt++
if mtim_bak ! mtim {fps=fps_cnt-fps_cnt_bak:fps_cnt_bak=fps_cnt:mtim_bak = mtim }
goto *main

実際に稼働させるPCでsettexが一回なのとgsquareが5回以上で
どちらが軽いか・・・

あ、ちょっと失敗

sptwpがスクリーンの中心座標を0,0として指定する形になってた・・・
使うときは スクリーン座標X-ginfo_winx/2 見たいにするか

137行目辺りの
> fvdir fv,tc*sx*cdz,tc*sy*cdz,-cdz
を

	fvdir fv,(sx-whsx)*cdz*tc,(sy-whsy)*cdz*tc,-cdz

に変更

addplateEx_AddObjの方はスクリーン座標そのままでOK
後、addplateEx_AddObjは傾けるのはY軸だけなので
指定Y座標がスクリーン中心を跨ぐ傾きには対応出来ない
Y軸回転だけでは無理なので・・・

暇人様、サンプルありがとうございます。
見た瞬間に「まさにこれだ！」とか思いました。すごいです、すごすぎます。
あの後必死にhgimg3のさわりだけ覚えて、プレートにテクスチャを貼り付けて何度も確かめて位置を合わせていたのですが、
これなら今までのスクリプトを流用できそうです。

課題やホームルーム企画や部活で大忙し…。高校生って大変ですね…。
みなさんも暑さにやられないように、体調を崩さないように、夏を過ごして欲しいです。
では、これから先は自力でなんとか頑張っていきます。
本当にみなさま、ありがとうございました。