キーを押し続けた時間経過による変化をつけるのであればそうしたい理由ができてくるので何の疑問も持たずにカウンターフレーム形式にするのです。カウンターフレーム形式を使って一定以上カウントしない処理をすれば無駄にカウントをし続けなくする事は可能ですよ。私ならカウント式がifなど分岐・関数の量・コード量が少ないなどの点で優れているなら採用します。[追記]わざわざカウントを止めるのはコード的にバグを生みそうで要注意です。汎用性が下がると思います。シンプル・コードの量が少ないのは何よりもバグの点でメリットだからです。【補足】処理を見て分かりづらいとか、それも候補外にする理由でしょうか。フィアさんにとってはカウントは気持ち悪いと表現して良い処理だと思いますので採用しないのも、それもフィアさんにとっての正解だと思います。【さらに追記】bese_manegeが気になったので。base_manageだと思います。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。6年前わたしの場合、自作や標準ではない特定のライブラリ関数を直接呼ぶコードは移植性が下がるので避けます。それと実装無しのプロトタイプで関数名など決めてしまうので、自然とインターフェースができていて、中身を実装するときはそもそもコピペの必要性が低いです。{}というふうにあらかじめ書いておくわけです。動かすために必要なところから中身の実装を進めていきます。わたしはこれを汎用化のためにやっているわけではありません。可読性も上がると思いますが、作業量を見通しやすかったりモチベーションを維持しやすいのでこういうやり方をしています。掲示板に投稿するときは冗長になるのでしません。大体コードの内容がわかって、こんな表現もあるのか!っと思っていて改良の仕方がわかったのですがどうしてもわからないところがあります。いう動きをしているのかがわかりません。するビット演算なのはわかるのですが、それを使うとどうして制御できるようになるのかがわからないです。いう仕組みだとは理解できたので改良は可能であれこれできるのですが疑問点が残っているのは問題なので質問させていただきました。私ならカウント式がifなど分岐・関数の量・コード量が少ないなどの点で優れているなら採用します。[追記]わざわざカウントを止めるのはコード的にバグを生みそうで要注意です。汎用性が下がると思います。シンプル・コードの量が少ないのは何よりもバグの点でメリットだからです。【補足】処理を見て分かりづらいとか、それも候補外にする理由でしょうか。フィアさんにとってはカウントは気持ち悪いと表現して良い処理だと思いますので採用しないのも、それもフィアさんにとっての正解だと思います。【さらに追記】bese_manegeが気になったので。base_manageだと思います。・・・・・え、カウンター止めるとバグがでるんですか?止める方向で改良してみたのですが・・・・。言いますかカウンター止めないと無限に増えてしまうためオーバーフローしませんか?ただのカウンターが気持ちが悪いのではなく、「無限に」の部分が気持ち悪いのですね私にとっては正解な事をやってるから一般的な書き方からどんどん離れていくのですね。わかりますがやめられない。わたしの場合、自作や標準ではない特定のライブラリ関数を直接呼ぶコードは移植性が下がるので避けます。それと実装無しのプロトタイプで関数名など決めてしまうので、自然とインターフェースができていて、中身を実装するときはそもそもコピペの必要性が低いです。{}というふうにあらかじめ書いておくわけです。動かすために必要なところから中身の実装を進めていきます。わたしはこれを汎用化のためにやっているわけではありません。可読性も上がると思いますが、作業量を見通しやすかったりモチベーションを維持しやすいのでこういうやり方をしています。掲示板に投稿するときは冗長になるのでしません。ISLeさんは先読みして計画性があるのですね。思いついたら即実行するため計画を練っても変わっちゃうのは問題かもしれませんね。6年前えっとISLeさんに非常に悪いのですが私の汎用関数のソースコードができました。ISLeさんのソースコードを元に(してたんですが原型が残ってません)作ってみました。カウンター式がカウンター止めるとバグがでるとのことなのでカウンター式ではなくスイッチ式です。普通の方にとっては汎用性はないのかもしれませんが改良はしやすいので、カウンターをとめるとバグが出るというのを解決できるのならカウンター式も作りますね。6年前>ただのカウンターが気持ちが悪いのではなく、「無限に」の部分が気持ち悪いのですねカウントのオーバーフローは2147483647カウント後に発生します。これが何時起こるかですが、一秒間に60フレームで一時間で60x3600カウントですから9942時間後に発生します。9942時間/24時間で414日後となります。事実上は無視出来る時間だと思います。>・・・・・え、カウンター止めるとバグがでるんですか?>止める方向で改良してみたのですが・・・・。必要もないコード入れるのはバグの元になると言う話だけです。少なくとも私にとってはカウンターストップは必要がありません。汎用性も失うことになりますので。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。いう動きをしているのかがわかりません。するビット演算なのはわかるのですが、それを使うとどうして制御できるようになるのかがわからないです。mouse_input_oldには(UpdateMouseInputTrigger関数を呼び出した時点で)前回のGetMouseInput()関数の戻り値が入ります。ビットが異なるときというのは、1.前回押されていたボタンが今回離されていたとき2.前回離されていたボタンが今回押されていたときとなります。その状態変化がそのまま各ボタンのビットに反映される仕組みです。mouse_input_tigger;}というのを^演算子1つで済ませているわけです。ついでに将来MOUSE_INPUT_*というシンボルが増えたとしても32ボタンまで変更なしに対応できるはずです。ISLeさんは先読みして計画性があるのですね。思いついたら即実行するため計画を練っても変わっちゃうのは問題かもしれませんね。わたしも思い付いたことをその場で実装することはしょっちゅうあります。何をしたいかを具体的にしてからコーディングするようにしているだけです。わたしが書いていることを読んでいたら分かると思いますが、わたしは基本的にコーディングが好きではありません。できるだけコードを書きたくないので紙と鉛筆(比喩表現)を使って落書きしている時間のほうが長くなります。このままコーディングを続けたらコピペスパイラル等の地獄に陥ると思ったら、すべてを一から書き直します。そこにはまったく計画性などありません。(追記)わたしがあらかじめ決めるのは方針ではなく、目標(ゴール)です。方針は常に変化します。えっとISLeさんに非常に悪いのですが私の汎用関数のソースコードができました。押しているあいだずっと押していると判定されるだけのように見えますけど。これでは最初の問題の解決に繋がらないのでは?わたしのコードでカウントが上がるのは押した瞬間だけで、押しっぱなしでは上がりませんよ。『何をしたいのか』が最初から明らかでない、あるいは途中で見失うからこういうことが起こるのではないですか?あと、毎回引数でキーボードを使うかどうかのパラメータを渡すのは使いにくいと思います。>カウントのオーバーフローは2147483647カウント後に発生します。これが何時起こるかですが、一秒間に60フレームで一時間で60x3600カウントですから9942時間後に発生します。9942時間/24時間で414日後となります。事実上は無視出来る時間だと思います。1.前回押されていたボタンが今回離されていたとき2.前回離されていたボタンが今回押されていたときその状態変化がそのまま各ボタンのビットに反映される仕組みです。いう仕組みなのですね便利なのは非常にわかるのですが使われるところを見ているのに使いこなせる気がしません。使う場面の経験がもう少しほしいところですね。ついでに将来MOUSE_INPUT_*というシンボルが増えたとしても32ボタンまで変更なしに対応できるはずです。わたしも思い付いたことをその場で実装することはしょっちゅうあります。何をしたいかを具体的にしてからコーディングするようにしているだけです。わたしが書いていることを読んでいたら分かると思いますが、わたしは基本的にコーディングが好きではありません。できるだけコードを書きたくないので紙と鉛筆(比喩表現)を使って落書きしている時間のほうが長くなります。このままコーディングを続けたらコピペスパイラル等の地獄に陥ると思ったら、すべてを一から書き直します。そこにはまったく計画性などありません。(追記)わたしがあらかじめ決めるのは方針ではなく、目標(ゴール)です。方針は常に変化します。一呼吸おくかおかないかの違いですね。押しているあいだずっと押していると判定されるだけのように見えますけど。これでは最初の問題の解決に繋がらないのでは?わたしのコードでカウントが上がるのは押した瞬間だけで、押しっぱなしでは上がりませんよ。『何をしたいのか』が最初から明らかでない、あるいは途中で見失うからこういうことが起こるのではないですか?やっぱりせっかく作っていただいたのに原型すら残さないコードになった事を怒ってるんですね。書いているうちにこうなってしまったんです。今回ISLeさんが書いていただいたコードは無駄じゃなかったのですよ。おかげで問題解決できたのです。コードでカウントが上がるのは押した瞬間だけで、押しっぱなしでは上がらない部分は確認済みですよ。キーボードを組み合わせようとするとうまくいかなかったのです。質問して答えていただいたおかげで無事に解決できたのです。それには大変感謝していますよ。あと、毎回引数でキーボードを使うかどうかのパラメータを渡すのは使いにくいと思います。マウスのみでも操作は可能ですが補助的にキーボードを使ってもある程度補助できるようにしたかったのです。これはプレイヤーを意識していたためです。何らかの事情でマウスが使えなくなる場合もあるかと思うのでその処置ですね(私自身がたまにマウスを使えなくなるので困ったものです)。ウィンドウズもマウスが使えなくてもキーボードを使って操作を多少できるので、私もそんな処置をしておきたかったのです。6年前>やっぱりせっかく作っていただいたのに原型すら残さないコードになった事を怒ってるんですね。さんは怒っているんじゃなくて、冷静に指摘しているだけだと思います。最初の主旨からズレているのでは?って事です。さんのコードは押しっぱなしでも0→1→0と変化します。押した瞬間の1フレームだけ1なのです。フィアさんのコードは押している間ずっと1です。さんの実装のほうが正しく見えますが如何なのでしょうか?>マウスのみでも操作は可能ですが補助的にキーボードを使ってもある程度補助できるようにしたかったのです。こちらもインターフェイスが良くないと指摘しているだけです。良い設計はないかという問いかけです。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。画面が変わった先でカーソルの下に押せるパーツがあったとき、押しっぱなしだとそれも押したことになってしまわないですか?最初の質問はそういうことだと思ってました。してあのコードで解決できたのか不思議だと思いました。思ったとおりになっただけでなければ良いですが。引数で渡すためには引数で渡す内容をあちこちへ引きずり回さなくてはいけなくなります。キーボードを使う使わないを切り替える関数を別に用意して、ふだんはどちらが選択されているかというか切り替え機能の存在そのものも意識しないで使えるようにしたほうが良いのではないでしょうか?仮にゲームパッドも使えるようにしたいと思ったら再びあちこち直して回るのですか?キーボードの扱いは、キーと処理をそのまま結び付けずに、キーと機能、機能と処理と分ければ良いと思います。決定やカーソル上下といった機能ごとにビットに割り当てて管理すれば、ビット演算が使えますよ。仮にゲームパッドも使えるようにしたいと思ったとき、機能をセットするだけでその先は変更する必要がありません。余談ですが、ビット演算を使ってチャタリングを回避することもできます。カウンタ方式でもビット演算を併用する場合があります。さんの実装のほうが正しく見えますが如何なのでしょうか?あの関数のおかげで完全に誤動作を全て解決できました。カウンター形式を使い始めたらいらないとわかったので大きな関数に組み込みました。#こちらもインターフェイスが良くないと指摘しているだけです。良い設計はないかという問いかけです。上で言った大きな関数にくみこんだ時にそこら辺を修正してみました。改良の余地はありそうなので少しづつ改良しています。質問の仕方がどうやって言えば伝えられるかをわからなかったので、回答者に捉え方が違ってしまったのは申し訳ありません。私の元のスイッチ形式ですが無限数を扱わないだけで、カウンタフレーム形式と同様の処理をしていました。言うわけではありません。今は薦められたカウンター形式を使っているため、ああこの関数全くいらんわとわかったので、大きな関数に組み込んでますけどね(カウンター形式だと大分ソースコードが短くなりました)問題はfor文の時にスイッチ形式でやる場合どうすればいいかわからなかったのですが、今回の回答でこうすればいいのかっとわかりました。引数で渡すためには引数で渡す内容をあちこちへ引きずり回さなくてはいけなくなります。引数で渡して~っと言うのは本来なら別のファイルに値を渡す時にやるべきでしたね。予断ですが別のファイルに値を渡すために関数にやたらといろいろ引数を渡しまくったら長くなりまくった関数がひとつあります。これも改良した方がいいと思うのですが『どうすればいいかわからん』状態です。キーボードを使う使わないを切り替える関数を別に用意して、ふだんはどちらが選択されているかというか切り替え機能の存在そのものも意識しないで使えるようにしたほうが良いのではないでしょうか?仮にゲームパッドも使えるようにしたいと思ったら再びあちこち直して回るのですか?大きな関数でどちらを使うかを選択できるようにしてみました。改良の余地はありそうなので少しづつ改良しています。ゲームパッドは使わないです。それ以外に使えるのかどうかはわからない)に購入する必要があるため、標準的なものではないと考えています。思いゲームパッドは使いません。余談ですが、ビット演算を使ってチャタリングを回避することもできます。カウンタ方式でもビット演算を併用する場合があります。ビット演算は確かに使いこなせればいろいろ可能性はあると思います。「キーボードとマウスは標準装備なので必要」というのと「ゲームパッドは標準装備ではないので不要」というのはコストが同じだと思いますが。前からわたしは「要・不要を考えること自体が不要」だということを言っているのですがどうにも伝わらないようです。6年前コードについてはざっとですが理解したつもりです。ボタンにカウンタがあるのではなくて別にカウンタがあるので、それで連続して押されるのを防いでいるのですね。理解しやすい形で実現されたのだと思いますし確かにガードは出来ていると思いますが、ISLeさんのものよりもかなり面倒なことをしていると思います。非常に申し訳ないですが、現状は全体的にコードが冗長でバグになりやすくメンテナンスが困難だと思います。似たようなコードがアチコチに見受けられますので、関数化やループ化(情報配列の利用)など工夫の余地が沢山あるのではないでしょうか。同じこと実現するのに、たぶん1/2から1/3のコード(もしかしたら、もっと短く出来るかもしれません)で実現できてメンテナンス性もよく出来ると思います。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。ミクプラは自由にリンクできます。