プログラマ専用SNS ミクプラ

KEYONN

ジョイパッドの（連続押しダッシュの）フラグを立てるのに、持っている書籍でシューティングゲームアルゴリズムマニアックス（松浦健一郎さん）より STAGE04：武器のコマンドショットで解決しました。なお、ニュートラルを取るのに、#define NEUTRAL 1とありますが、実際には、判定されていない模様かつ、上下左右ボタンしか判定していないと思われる為、入力履歴とコマンドの初期化の為の関数 void InitCommandShot()内の Command[0].Length=4; Command[0].Limit=30; Command[0].Input[0]=UP; Command[0...

KEYONN

すみません、基本的には出来ないです。
もしくは、方向別に関数を作り直すという事なら、できなくは無いです。

KEYONN

すみません、返信が遅くなってしまいました。しばらく、忙しかったのと、掲示板に書き込めなかったのでごめんなさい。ブラウザをfirefoxに変えてから、ログインできなくなりました。パスワードの保存機能のせいかもしれないです。今は、googlechromeで書き込んでいます。あと、参考になりそうなソースを書き込んでくれたのは嬉しいんですが、先に作ったソース（自分で作ったソースの方が自分にとっては分かりやすい問題）だったので、こちらに手を付けました。しかし、今度は弾がでなくなったり、いろいろ問題が出始めたので、何が原因か分からなかったのも返信が遅れた理由です。今も理由がわかりません。 i...

KEYONN

int CheckJoyStickPlayer1(int Dir,int FrameTime)；
は、どうやら、やはり間違っていたようです。
例えば、上ボタンを押していて、一旦離して、違うボタンを押すと、連続で押したと判定されてしまいます。
何が間違っているかは分かりません。

KEYONN

int CheckJoyStickPlayer1(int Dir,int FrameTime) { //同じ組み合わせの方向キーを、一定時間内に、 //ニュートラルを挟んで2回押したことを検出する、 //という条件であればもっとシンプルに表現できると思います。 int p1; int dir[4]={8,1,2,4}; p1=GetJoypadInputState(DX_INPUT_KEY_PAD1) ;//joytypeが0ならjoypad1 static int keytime[4]={0}; static int prevbotton[4]={0}; static int i=0; s...

KEYONN

フローチャートはこんな感じになったのですが、多分間違ってますね。
一定時間の時間の概念が無いので。。。
もう一回作ってみます。

KEYONN

≪余談≫ 　この関数には秘密があります。　実はこの関数は返される値の各ビットが各ボタンに対応していて最大で２８個のボタンの状態を調べることが出来ます。各ビットの構成は以下のようになっています。　ビットが１になっていれば押されていることを示し、０の場合はおされていないことを示しています。 (MSB)上位ビット　　　　　　　　　　(LSB)下位ビット BBBBBBBBBBBBBBBBBBBBBBBBBBBBURLD D・L・R・U：それぞれ方向キー下・左・右・上　　B:ボタン　つまり下ボタンの状態を知りたい場合は int DownState ; int InputState ; In...

KEYONN

この文字列を見て気付いた事があります。
おそらくIsleさんはテーブルを使って判定すれば効率化するという事を言いたかったのではないかと
。
int keytable[4]={PAD_INPUT_UP,PAD_INPUT_DOWN,PAD_INPUT_LEFT,PAD_INPUT_RIGHT};

これで、テーブル化できました。あとは、for文なり、while文なりで、ループで読めば良さ気ですね。

KEYONN

#同じ組み合わせの方向キーを、一定時間内に、ニュートラルを挟んで2回押したことを検出する、
#という条件であればもっとシンプルに表現できると思います

ニュートラルというのは、何も押していない状態ですよね？
それは、つまり、DXLIBにおいて、ジョイパッドの全てのボタンが何も押されていない状態なのか、
方向キーが何も押されていない状態なのか、どちらなのでしょうか？

一定時間内に２回というのは、おそらく実装できると思いますが、上のニュートラルの意味が少し分かりづらい
ので質問させてもらいました。

KEYONN

やっと実装できました。が、実際のダッシュの実装は加速度をつければいいだけだから、自明です。書籍のソースコードを参考にしたので、アルゴリズムだけ書いておきます。誰かの役に立てばいいです。 int CheckContinueJoyStick(int ジョイスティックのタイプ,int 方向) { //Direction ////0--up 1--down 2--left 3--right int p1,p2;//p1は、ジョイパッドのタイプによって受け取る値が違う p1=GetJoypadInputState(DX_INPUT_KEY_PAD1) ;//joytypeが0ならjoypad1 p2=...

KEYONN

MSDNライブラリで見た限り、このジョイパッドプログラムに関してはGetTickCount()を知って
成果はありませんでした。WINDOWSが起動したか、プログラムが起動したときに
タイマーが始まると思っていたのですが、WINDOWSが起動した時からのようです。

[追記]戻り値がＤＷＯＲＤでした。もしかすると、ここに問題点があったのかもしれないです。
戻り値に代入していたのは、intでしたから、そこに問題点があったの可能性はあります。

KEYONN

int CheckContinueJoyStick(int joytype,int joybotton) { int p1;//p1は、ジョイパッドのタイプによって受け取る値が違う if(joytype==0) p1=GetJoypadInputState(DX_INPUT_KEY_PAD1) ;//joytypeが0ならjoypad1を else p1=GetJoypadInputState(DX_INPUT_PAD2) ;//joytypeが0以外ならjoypad2を static int presstime[2]={0};//押した時間を計測するための変数 static int pre...

KEYONN

//どうしても描画と計算を分けなければいけないといった宗教上の理由がなければ、
//printfDxを使ってみてはいかがですか？
//DrawFormatStringなどの描画とは(多分)独立して描画されるはずです。
ありがとうございます。おかげで、関数内部からプリントデバッグできました。
どうやら、presstime[0]に代入されないみたいです。何故かはまだ分かりませんが。。。

KEYONN

//もっと沢山DrawFormatStringを埋め込んで問題の切り分けを行いましょう。

//ジョイパッドでボタンの押下状態はちゃんと検出できているのか、
//検出きていることが確認できたとして、連打した時の時間差の値はどうなっているか確かめてください。
DrawFormatStringを埋め込みにくいのは、３Ｄアクションゲームでフレームスキップを行うために
描画処理と更新処理を分離しているからです。現段階では、関数Draw()内に全てその中に含めて自作関数や
ＤＸライブラリの関数などが入っています。という訳でデバッグ中です。
しばらく待ってて下さい。

KEYONN

お久しぶりです。KEYONNです。DXLIB依存ですが、ジョイパッドでの方向キーの連打によってダッシュする仕組みというか、連打をどうやって判定するかが知りたいです。連打というのは、ここでは、２回カチッカチッと押す感じの事を指します。とりあえず、キーボードでも動作させる為に、関数を作ったのですが、それは上手くいきました様子？です。というのは、プリントデバッグみたいに、関数の戻り値を元にフラグを立てて DrawFormatStringで"KEY OK!!"みたいに表示させる事が出来たので、恐らく上手くいっていると思われます。その関数を書きます。 int CheckContinuePre...

KEYONN

モニターは詳細設定を見る限りでは６０Ｈｚでした。
何が原因かは分かりませんが、とりあえず、作業進めたいと思います。
Blenderのモデリングを勉強中です

KEYONN

＞PC版セガラリー・チャンピオンシップはソフトウェアレンダリングで30FPS出てましたけどね。
＞それも初代Pentium時代に。
ソフトウェアレンダリングは面白そうですね。ただ、あの環境で30FPSは驚異的です。
全てi386のアセンブリ言語なのでは？

KEYONN

＞本当に描画の動作だけが遅いのか、処理も含めて遅いのかによって対処が変わります。はい。＞ＣＰＵ側が遅い場合はコードはここのが参考になると思います。＞「フレームスキップについて • C言語交流フォーラム　～ mixC++ ～」＞viewtopic.php?f=3&t=11722 ちょっと見てみました。管理人さんのプログラムすごいですね。＞ただし、レースゲームですので画面表示をスキップしても車の体感速度は維持しないといけません。＞fps_getSkipFrameNum()で経過時間を移動距離に反映するようにしてください。画面表示をスキップって具体的にどういうことをやればいいのか分か...

KEYONN

static int FPS=0; static int NowTime=GetTickCount(); static int NowFPS=0; if(GetTickCount()-NowTime>1000) { NowFPS=FPS; FPS=0; NowTime=GetTickCount(); } DrawFormatString(0,0,GetColor(255,0,0),"FPS=%d",NowFPS); FPS++; と思ったらこのコードで調べたら、ＦＰＳが１０以下でした。敵の車を全て描画対象から外してもＦＰＳが５０以下でした。

KEYONN

あと、このパソコンは随分古くて処理落ちしてしまいます。
このゲームが遅くてイライラしてしまいます。
そこで、いろいろ調べたら、フレームスキップという方法があるのに気づきました。
http://www.c3.club.kyutech.ac.jp/gamewi ... (2D%CA%D4)
ＦＰＳを１５くらいにすればなんとか収まるんじゃないかと考えています。
カクカクしてしまうのは仕方ないです。

KEYONN

＞私もそう思いますが、ちゃんと動いているなら無理して掲載の必要はないです。＞いやな予感がするのは、プレーヤーの車を動かさずに地形を動かしているので＞CameraPosが必要という理由じゃないかという点です。地形は動かしてませんよ。カメラと車をそれぞれ動かしています。地形を動かしているなら、どうやってレーダーとか、マッピングの処理を行うのか良く分かりませんし。。。あと、ちゃんと動いていますよ。おかげさまでズレは直りましたし＞mayaじゃなくてもBlender(無料)で出来ると思いますが。 Blenderは良いソフトですね。無料ですし、GIMPとの相性も良さそうです。それに、パーテ...

KEYONN

>自プレイヤーと敵プレイヤーの座標が確かに必要だと思いますがCameraPosが必要な理由が >イマイチわかりません。う～ん、ソースを載せるしかないようですね。 >あとDrawSoftImageって遅くありません？ >マップは別に描画用にLoadGraphで読んでDrawGraphしたほうが良いと思います。遅いというか、ちょっと凝った３Ｄモデルを描画する方がむしろ遅いです。まあ、それぞれ環境の違いがあるので、LoadGraphでDrawGraphにしました。 >それこそ、方眼の３Ｄマップデータと方眼イメージマップで座標ズレの原因を探るべきです。どうやら、座標更新後にマップのレーダーとい...

KEYONN

>>カメラとは別にCarPosという変数とEPosという変数があります。 >>それを参照すれば良いと思います。 >それだとCameraPosは出てこないですよね？ >つまり「XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい」としては >不要ということでしょうか？いえ、どちらにせよ、マッピングする必要があります。あとは、現在、LoadSoftImageで、読み込んだマッピングしたい２次元画像をDrawSoftImageで半透明描画して、自プレイヤーと敵プレイヤーも位置で描画しています。しかし、微妙にずれているんですよね。何が原因かは分かりませんが、いろいろやってみます。...

KEYONN

＞テストプログラムを書くほうが簡単だと思いますが。＞わざわざ、開発中のコードを直したのでしょうか？はい。＞カメラはプレーヤー車の位置を表すのですね？＞しかしカメラから車の挙動を計算するには面倒だと思うのですがカメラとは別にCarPosという変数とEPosという変数があります。それを参照すれば良いと思います。＞mqoファイルではダメなのでしょうか？＞そのままＤＸライブラリは読み込めるはずです。 mqoファイルで読み込んで見ます。＞先のことを考えて開発するかどうかの問題ですが、このコードを流用しないなら問題ないでしょう。全て行列とベクトルに計算し直した方がいいでしょうか？＞車...

KEYONN

ＫＥＹＯＮＮです。ちょっと外出していました。なので返信が遅くなってしまってすみません。＞Ｚ軸の方向もそうですが、簡単に確認できることを質問してしまうのは、＞KEYONNさんにとって良くないことだと思うので＞Ｚ軸と「MV1SetPosition( int MHandle, VECTOR Position ) ;で指定したのですが、＞指定される座標がどの地形の部分なのかよく分からないのです。」を確認する方法を考えてみてください。＞これは、テスト方法とか考えるにも必要なプログラマーにとって＞大事な思考プロセスをしていない事になるからです。＞難しくはありません。ちょっとした工夫をするだ...

KEYONN

あまり関係無いですが、今日はもう寝ます。疲れました。
頭を使うと眠りにくくなるみたいですし

あと、スクリーンショットだけ画像を添付します。

KEYONN

＞初の本格的な３Ｄレーシングゲームを作っていますが
ちなみに、分かるとは思いますが、”初”のというのは僕にとって、初めて本格的な３Ｄゲームを作っているという
意味です。

あと、旋回速度は、

コード:

YRotate=((float)(YRotate))+(3.5f/(Sp+0.1f));

という計算式を使っています。
スピードが高くなればなるほど、旋回速度は低くなるので、ブレーキを踏み、スピードを落とすと
曲がりやすくなります。Spに0.1を足しているのは、０除算エラーを防ぐためです。

KEYONN

分かった事があります！！
この計算をするには、メタセコイア側で左下を（０，０、０）に合わせないと駄目だということです。
でも、まだ、GetXがマイナスになったりするので、よく分からない事が多いですが、頑張ります。

KEYONN

どこがおかしいかというと、DrawFormatString関数で、GetXとGetYの値を調べたのですが、
GetYの値が途中からマイナスになっているのです。

KEYONN

＞３次元空間として地形を組んでしまった方が早いと思います。＞ただ、人間に見える地形と当たり判定で使う地形は分けたほうが楽だと思います。＞→　ここで地形ツールを作る必要が出てきます。地形ツールは、既存のモデリングソフト（メタセコイア）を使いました。３Ｄなのに、平面な地形です＞>OpenGLの右手座標系なら分かるのですが、DirectXの左手座標系は、＞>Ｚが奥に行くほど足されていくという考えであってますでしょうか？＞カメラにおける光軸方向の事でしょうか？＞OpenGLだと奥がマイナスでDirectXは奥がプラスですね。おお、そうでしたか、やはり合っていたようです。 >先ほどの３...

KEYONN

[1] 質問文　[1.1] 自分が今行いたい事は何か＞初の本格的な３Ｄレーシングゲームを作っていますが、地面との当たり判定や、道路ではない緑の部分（草地）との当たり判定、レーダーの処理、坂道の上り下りがしたいです。　[1.2] どのように取り組んだか(プログラムコードがある場合記載) まず、地面との当たり判定は、坂道がないため、ZX平面を平行移動する形となるため、２次元画像（orp.png:4360,4360)のZX平面と対応する（３次元座標のZが２次元画像のY座標で、３次元座標のXが２次元座標のX座標にして、色を取得し、緑色RGB(0,200,0)ならスピードをだんだん遅くする...

KEYONN

意図通りというか、計算の仕方がよく分からなかったので、ソースを改造して、でたらめの計算をしている可能性があります。本当は、横スクロールバーが、右にいけば、ノートは、左に行って欲しいんです。そして、横スクロールバーが左にいけばノートは右にいってほしいんです。何かベースにしているソースコードがあって把握していない事があるんですね？少なくともN.StartXRtn(i)を使った表示時に371を足すのやめれはスクロールには追従しているようには見えます。 ※　描いちゃいけない所に描くとかガードをしていない問題は除きます。 N.Searchでは、よくない関数名なのですか…、N.NoWorkSea...

KEYONN

マジックナンバー371は、横スクロールバーのスクロール値nPosの初期値です。元のコードですが Rectangle(hdc,N.StartXRtn(i)-nPos+371,N.StartYRtn(i)-vPos, N.EndXRtn(i)-nPos+371,N.EndYRtn(i)-vPos); 登録時に N.Search(M.StartX+nPos,M.StartY+vPos,M.StartX+16+nPos,M.EndY+vPos,note); としてますので表示でN.StartXRtn(i)-nPos+371だと M.StartX+nPos-nPos+371の計算と同義です。これは...

KEYONN

書くのを忘れていました。ネットカフェからの書き込みです。

KEYONN

この表示ですが元から371が足されているようです。 Rectangle( hdc, N.StartXRtn( i ) - nPos/* + 371*/, N.StartYRtn( i ) - vPos, N.EndXRtn( i ) - nPos/* + 371*/, N.EndYRtn( i ) - vPos ); [追記]　他にも表示上の問題がありますが、マジックナンバーやら色々出てくるので何がしたいのか分からない状況です。座標に足す371と言うマジックナンバーは何なのでしょう？一番の問題は、このシーケンサの目的としている操作が分かっていなことかも知れません。マジックナンバー371...

KEYONN

ISLe様、回答ありがとうございます。
これで、ファミコンにもNESASMで実装できそうです。

ところで、効果的な実装という意味は、少ないデータでたくさんの移動が
出来るという意味です。

なので、これなら、少ないデータでたくさんの移動ができそうです。

ありがとうございました。

KEYONN

旧tkozから名前を変えました。どうぞ、よろしくです。ファミコンをcc65では実用的な速度が出ない事が判明したので、去年の暮れ辺りからNESASMで縦スクロールSTGを作っています。ところが、敵の移動ルーチンを考えたとき、以前DXライブラリ製のSTGでベジェ曲線で敵を移動させたことがあるのですが、その時に調べたら、どうやら整数演算でベジェ曲線が使えるらしい事が分かっていました。なので、今回のプログラムにもそれを適応させたいと思い、ここのページ　http://studio-rain.cocolog-nifty.com/blog/2008/07/post_c4f5.html を参考...

		9月 2025
日	月	火	水	木	金	土
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

検索結果 37 件

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

DXLIBにおけるジョイパッドでの方向キーの連続押しダッシュの仕組みについて

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

XZ座標と任意の大きさと場所にで２次元画像とのマッピングを図りたい

Re: (WINAPI)Midiシーケンサの製作（基本機能のみ）

Re: (WINAPI)Midiシーケンサの製作（基本機能のみ）

Re: (WINAPI)Midiシーケンサの製作（基本機能のみ）

Re: (WINAPI)Midiシーケンサの製作（基本機能のみ）

Re: ファミコンSTGでの効果的な敵の移動アルゴリズムおよびベジェ曲線

ファミコンSTGでの効果的な敵の移動アルゴリズムおよびベジェ曲線