3Dモデルの編集について(DXライブラリ)Mesh内の頂点数と頂点座標と三角ポリゴン数まではこれで取得できます。やってて悲鳴上げそうになってきた。ファイルからの読み込み時、文字列先頭に不明な文字すいません。コンパイル通らないと思うのでコンパイル通るものをお願いします。その処理をするならば、今は1文字ずつ格納していると思いますがFileRead_getsで1行読み込んでやるといいかもしれません。ファイルからの読み込み時、文字列先頭に不明な文字iとjの初期化がどこでされているのか、わかりませんでした。3Dモデルの編集について(DXライブラリ)まだエアホッケー作ってる最中なのですが、頑張ってサンプル作ってみます。3Dモデルの編集について(DXライブラリ)ググってみましたがここを見ればXファイルのデータ構造がわかると思います。親切に書いてあります。残ったmeshデータを描画する感じになるのかと思います。Xファイルのmesh内を保持しなければなりません。どのファイル形式で保存させるかによってデータの持ち方が変わってくると思います。多倍長演算を用いた平方数19行目と39行目と10行目の引数の数があっていませんのでエラー原因はそこかと思います。多倍長演算を用いた平方数なのでURLを投げました。文章をそのまま受け取ります。任意の文字を10にしてあります。配列と画像やるならこうしたらいいかと思います。あとはDrawGraph(50,50,image,true)のiの添え字を設定してやれば出来るかと思います。結論から言うと出来ます。テストするので待って下さい。フレーム内の人数カウント面白そうなことやってますね。すごい難しそうですね。何かマーカーとなりえるもので人数を確認しないといけないのではないでしょうか?っと単純に思いました。X-BOXのキネクトのように人間の体を判別しているはずなので、もしかしたら参考になるかもしれません。都会の大きな本屋さんへ行かないと専門書売ってないですね。ゲームループについて質問ですいきなりDirectXからやるのはハードルが高いですね。順番に基礎から覚えて行った方がいいと思いますよ。Win32を覚えてWindowsのメッセージのやり取りの仕組みを覚えてからDXライブラリ使うと楽にできますよ。エアホッケーみたいなゲームの当たり判定についてGRAMさんへ見させてもらいました。素晴らしいの一言です。これを参考にさせて頂きたいと思います。ありがとうございました。回答をして頂いた皆様もありがとうございました。残り丸いラケットとひし形のラケットが残っておりますがまた挫折したら質問させて頂きたいと思います。これにて解決ということで閉じさせて頂きたいと思います。本当にありがとうございました。スポイラーを表示こんなタグあったのですね。龍神録プログラミングの館、16章16章の読み込んでるところのソースです。最初の2行読み飛ばすって書いてありますね。龍神録プログラミングの館、16章カンマ区切りならそれで正解だと思います。龍神録プログラミングの館、16章Excelでもcsvファイル出力できますが量が少ないならテキストでもいいと思いますよ。先に言いますとcsvにはある一定のルールがあるので、読み込むソースコードがどの形式に対応しているか調べないとダメかもしれません。龍神録プログラミングの館、16章ここ読んでみて下さい。http://e-words.jp/w/CSV.html実体はテキストファイルである以上です。龍神録プログラミングの館、16章まずは拡張子csvとはどんなファイルなのかを調べて見るとわかると思いますよ。違いについて説明してください。いうのがバグの原因とかにも成るうるのでコーディングするときは一貫性を持ってコーディングした方がいいと思いますよ。自分ならこう書きます。エアホッケーみたいなゲームの当たり判定について最新ソース貼っておきます。あとで自分なりにコードを書いてみます。1移動する円盤と長方形のあたり判定を実装する2長方形はマウスに追従する3円盤の速度には長方形の速度が加算される4すり抜けを回避するこれらを実装するよう頑張ります。基本的にはカプセルとAABBの衝突判定に、衝突点を計算するようなプログラムになると思います。GRAMさんへごちゃごちゃになってきたので、こちらも変数をまとめて書き直して見ます。使用をやめてcross_chkで線分交差を判定する関数をサンプル見て作りました。これでintとfloatの型変換の警告は出なくなります。ソースも貼っておきます。作りかけのところもあるのでコメントアウトしてある処理もあります。添付ファイルは念の為、個々でウイルスチェックを行ってください。処理的にはguard_frame_chkがちょっと複雑かもしれません。エアホッケーみたいなゲームの当たり判定についてnonさんへ頼もしい回答ありがとうございます。あとDXライブラリの関数でSegment_Segment_MinLength()を使って線分の距離で判定しているのですが肝心のSegment_Segment_MinLengthの中身が見えてないので、自分で作って見ることにします。四角いのがラケットとします。動作はゲームセンターに昔あったエアホッケーだと思ってください。抵抗や力学とかはまずは無視します。四角いラケットの上面にボールが当たると仮定します。わかりやすいようにボールの移動量はX=10,Y=10としてボールは右下へ向かって移動していると仮定します。そこで四角いラケットを上へ移動した際に極端な例を上げると以下のようにめり込んでこうなると思います。ラケットの速度が100を超えている場合に、明らかな矛盾がありますよね。減算の条件で0にならないというのもイメージができませんが、やはりもっと具体的な条件を示していただきたいかなと思います。ここですかね?softyaさんので正解だと思います。ヒントはINPUT構造体です。sizeof(mouse_info));違ったらごめんなさい。[雑談?]c++の分かりやすいプログラム人のプログラムをまずはパクって使ってみて覚えます。こんな処理のときはこれを使うみたいな、お決まりなパターンが見えてくる気がします。自分も人のことは言えませんが極力無駄な処理を減らして保守しやすく、見やすいようにすることを心がけています。わかりやすいのは第3者が見てもわかるソースを作ることを心がけると良いと思います。最低限、インデントとコメントくらいは必要かと思います。自分で作ったプログラムでもコメントがない場合、1ヵ月後に見たらさっぱり訳がわからないこともただあります。こればっかりは自分で試行錯誤を繰り返して経験を積んでいくと良いのかと思います。エアホッケーみたいなゲームの当たり判定について言葉通りに受け取ってみます。円とおっしゃってますが点じゃなくて大きさのある円なのですね。速度の加算は簡単に1フレームで動いた分をそのまま速度にして100以上の場合はデフォルトで100を設定しております。速度の減算は無条件でデフォルトのボールの速度しようと思います。ボールの移動方向とラケットの移動方向が違う場合は、わかりやすく言うと正面衝突になりその時にスピードを上げます。その逆にボールの移動方向とラケットの移動方向が同一の場合は、スピードを下げます。自分で作ったサンプルコードなのでボールとラケットのすり抜けが防げればOKです。スピードアップを実装したコードです。ラケットでも同じことをすれば良いのかなと思いました。どんなものかというと完全にエアホッケーのルールです。ラケットの移動速度が速いときにボールを貫通しています。そこで今対処したのは以下になります。ラケットの面に対して線分を作成してボールの線分とラケットの線分の交差を判定して当たり判定を行っています。エアホッケーみたいなゲームの当たり判定についてちょっとずつ当たり判定が強くなってきましたがマウスを高速に動かしたときに、まだ上手くいってないですね。すり抜けを回避できるかやってみようかと思います。ご指摘がありましたらご教授願います。マウスのプログラム制御方法について(winAPI-C)クライアント側の処理はこんな感じになるかと思います。サーバー側はソケット開いて待っていればいいと思います。ここでポイントになるのはWM_LBUTTONUPです。WM_LBUTTONDOWNにはしませんでした。WM_LBUTTONDOWNで判定すると押している間にもいっぱいイベントが発生するからです。よってクリックを押してから離された時に判定しています。あとはコメントしてあるところにそれに対応した処理を書けばよいかと思います。マウスのプログラム制御方法について(winAPI-C)AのPCからBのPCへやり取りするのでしょうか?それとも同一のPC上でのスレッド間通信でしょうか?送信側と受信側のソースコード見ないとなんとも言えませんね。連打プログラムすぐに実装できそうだったのでやってみました。30フレーム毎に速度を1減速させてみました。frame_cntです。mouse_input()で左クリックしたらスピードを上げる処理をしています。speed()でspeed関数を30回通過したら速度を1減速しています。ちなみに今は初期値の2よりもスピードが下がらないようにガード処理も入っています。ball_dxとball_dyが1フレーム内で移動する移動量になりますのでこれが速度になります。間違いなくフリーズするレベルかと思います。聞くかというと無駄な処理を回避するためです。パケット送信するならばできるだけ無駄を省き通信回数を減らす方法を考えます。あとは無駄な処理をさせないこと。ツリービューでディレクトリ&ファイル列挙こっちの方がサンプルとしていいと思いますhttp://www.geocities.jp/ky_webid/win32c/054.htmlキーワードはFindFirstFileとFindNextFileです。昔オープンソースをいじってた時に指定したフォルダ以下からmp3ファイルを参照するのをいじったことがあるのですがヒントとしては再帰関数でフォルダとファイルを読み込んで行きます。この辺でググれば何かわかるかもしれません。エアホッケーみたいなゲームの当たり判定についてNo7とNo8で作った2線分交差はラケットの前の位置から現在の位置までの線分でこれは実際にやりたい処理とは異なり、そこをアレンジしてNo14を作って見ましたこの線分なら判定できるはず、予想ですけどこの処理でやらないといけないのはボールの線分とラケットの当たり判定のある線分の交差を判定すれば対応できるのではないだろうかという発想です。足りないよとかありましたらご指摘お願いいたします。エアホッケーみたいなゲームの当たり判定について予想ですけど、この最新ソースから1フレーム前の位置と現在の位置取得して1フレーム内のラケット移動分をループさせて2線分交差を行えばすり抜けは回避できるのかなと思っておりますがあってるのかな。頑張って作って見ます。エアホッケーみたいなゲームの当たり判定についてnonさんへやってみてわかりました。129行目と130行目が必要だったみたいですね。ありがとうございます。エアホッケーみたいなゲームの当たり判定について少し当たり判定がよくなりました。わかってきたかもしれません。次はラケット押し出した時にまだすり抜けてるのでそこを実装してみます。drawで中心座標から減算して描画座標に直しています。ご指摘通り手抜きです。仕様は以下になります。ボールとラケットが重なった時にボールを反射させたいです。それとエアホッケーのようにボールをラケットで押したときにボールのスピードを早くしたいです。エアホッケーみたいなゲームの当たり判定についてさっきのfor文の失敗の修正して作って見たのがこれです。4面あるラケットの上面だけの動きを作って見ましたがすり抜けてますね。理屈的にはこれでいいはずだと思っているのですが、上手く行きません。何が足りないのでしょうか?ご教授願います。※81行目と83行目のfor文全然違うことに気がつきました。エアホッケーみたいなゲームの当たり判定についてまだ何かが足りませんね。一歩前進した気がします。intからfloat変換は今は無視してます。ツリービューでディレクトリ&ファイル列挙win32API使えば簡単だと思います。エアホッケーみたいなゲームの当たり判定についてmyuon_myonさんへ物理の数式見てもさっぱりでcodeならわかりそうなのでcode見て頑張ってやってみます。ありがとうございます。ここからどうのに変更していけばいいのかがさっぱりで困ってます。このように前後左右に動くラケットでラケットの当たり判定をどうしたらよいのか困ってます。試作品のサンプルのcodeは以下になります。知恵を貸していただければ幸いです。windowsアプリケーションの背景を透過させたい横槍ですいません。CALLBACKのWM_CREATEにSetLayeredWindowAttributesを追加しないと透過しないと思われます。ミクプラは自由にリンクできます。