ゲーム開発

初期の3Dゲームの多くは、あなたが楽しそうに歩き回り、突然すべてが黒くなるという問題を抱えていました。そして、あなたが歩いていたシーンの中空のファサードのシェルのように見える島が上の距離まで上昇しました。あなたが世界から落ちたからです。これはBethesda Softworksにとって長年にわたる特定の問題であったことを覚えていますが、彼らだけではありませんでした。野生で見たのは久しぶりなので、私たちはそれを過ぎてしまったようです。私の質問は2つの部分です。 1）この原因は何ですか？（私の推測では、ポイントモデリングされたキャラクターの位置と相互作用する、ポリゴン間の浮動小数点精度に関連するシーム、つまり、フロアチャンクAが位置1.0で終了し、フロアチャンクBが位置0.9998で開始し、マイクロ秒の位置が0.99992、そしてブーム、あなたは世界を転落します。しかし、それは単なる推測です。） 2）どのように修正されましたか？

14 3d  3d-meshes  scene  floating-point 

私はいくつかのベクトルロジックに取り組んでいるので、この不等式を単純化することでプロセッサ時間を節約できますか？ distance(vector1, vector2) < distance(vector1, vector3) vector1どちらの場合も同じことが繰り返されます。

14 vector 

OpenGL 3.3およびGLSLバージョン330で動作するスカイボックスを取得しようとしています。 ウェブ上のどこにも完全に最新のOGLスカイボックスチュートリアルが見つからなかったため、古いものを最新化しました（頂点などのglVertexAttribPointer()代わりに使用gl_Vertex）。それはほとんど動作していますが、2つの主要な詳細： スカイボックスは空の三角形に似ており、テクスチャはひどくゆがんで伸びています（それらはスターフィールドであると想定されていますが、黒の背景に線が描かれています）。これは、古いチュートリアルを完全に正しく移植しなかったためだと99％確信しています。 これが私のスカイボックスクラスです。 static ShaderProgram* cubeMapShader = nullptr; static const GLfloat vertices[] = { 1.0f, -1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f, -1.0f, -1.0f, -1.0f, 1.0f, -1.0f, -1.0f, -1.0f, -1.0f, 1.0f, -1.0f, -1.0f, 1.0f, 1.0f, -1.0f, 1.0f, -1.0f, 1.0f, 1.0f, -1.0f, 1.0f, 1.0f, 1.0f, -1.0f, 1.0f, 1.0f, -1.0f, …

14 c++  opengl  glsl  cubemap  skybox 

GLSLフラグメントシェーダーを使用して画像の色相を変更しようとしています。Photoshopの色相/彩度調整レイヤーに似たものを実現したい。 次の画像では、私がこれまでに得たものを見ることができます。緑色の正方形の色相を変更して右側の赤い正方形のようにしたいのですが、このシェーダーでは半分の赤い半分のピンクの正方形（中央の正方形）が得られます。 フラグメントシェーダーで行っているのは、テクスチャの色をHSVに変換してから、頂点シェーダーから取得したHSV色を追加して、色をRGBに変換し直すことです。 私は何を間違えていますか？ フラグメントシェーダー： precision mediump float; varying vec2 vTextureCoord; varying vec3 vHSV; uniform sampler2D sTexture; vec3 convertRGBtoHSV(vec3 rgbColor) { float r = rgbColor[0]; float g = rgbColor[1]; float b = rgbColor[2]; float colorMax = max(max(r,g), b); float colorMin = min(min(r,g), b); float delta = colorMax - colorMin; float …

14 opengl  shaders  glsl  opengl-es2  fragment-shader 

私は時々ゲームを説明するために使用される「カジュアル」という用語を見てきました。 「カジュアル」ゲームとは正確には何ですか？それらと通常のゲームの間に実際の違いはありますか？もしそうなら、何がゲームを「カジュアル」にしますか？

14 terminology  casual-games 

ランプシェーディングまたはランプとは何ですか？トゥーンシェーディングとは違うのですか、それとも同じコンセプトですか？ランプシェーディングとブリンフォンまたはランバートのスペキュラリティの計算方法はどのように異なりますか？

14 shaders  lighting 

物理エンジンは、たとえば、互いに近くにあるオブジェクトをグループ化し、すべてのオブジェクトではなくこのグループ内の衝突をチェックすることにより、その複雑さを軽減できますか？（たとえば、他のオブジェクトからの速度と距離を調べることにより、遠いオブジェクトをグループから削除できます）。 そうでない場合、球体（3d）またはディスク（2d）の衝突は簡単になりますか？ダブルループを作成するか、代わりにペアの配列を作成する必要がありますか？ 編集：弾丸やbox2dのような物理エンジンの場合、衝突検出はまだO（N ^ 2）ですか？

14 collision-detection  physics  optimization  physics-engine 

私の知る限り、垂直視野は次のように調整する必要があります。 fov = 2 * arctan(0.5*screenHeight / distanceEyeScreen); つまり、視野はユーザーの画面の距離と画面のサイズに一致する必要があります。 多くのFPSでは、水平FoVのデフォルト値は90°、垂直FoVのデフォルト値は60°です（16：9と仮定）。1つの例はCryEngineです。ただし、16：9 20インチ画面（可視領域の対角、つまり約40 cm x 25 cm）の場合、このデフォルト値では、ユーザーが視点を正確に見るために画面から20 cm目を見る必要があります。 そのため、計算を間違えたか、不適切なFoV値を意図的に選択する理由があるに違いありません。 90°horz / 60°vertのデフォルトFoVの理由は何ですか？

14 3d  camera  perspective 

エージェントが土地のために戦っているゲーム/シミュレーションを開発しています。私は次の図に示すような状況にあります。 これらのクリーチャーは歩き回っており、自由な場合は踏む土地を占有します。これをさらに面白くするために、エージェントが実際に土地を歩き回り、侵入者からパトロールするように「巡回」行動を導入したいと思います。 技術的な面では、各正方形はx,y位置として、またその辺の長さを表す寸法として表されます。また、誰が広場を占有しているかに関する情報も含まれています。すべての正方形はに保存されますArrayList。 パトロール動作を導入するにはどうすればよいですか？私が望んでいるのは、各エージェントがエリアの特定の部分をパトロールすることです（彼らはパトロールするエリアを自分たちの間で分割します）。私が見つけた主な問題は次のとおりです。 写真に見られるように、土地の面積は非常にランダムです。各方向の境界がどこにあるかを理解するのはかなり困難です。 エージェントはどのように地域をパトロールする必要がありますか？ 敵チームは中央から領土を奪う可能性があるため、土地のエリアはばらばらになる可能性があります。 私は、各方向に最も遠い正方形を取り、それらをエリアの境界として扱い、それらの境界に基づいて領域を分割するというアイデアを思いつきましたが、これには多くの無関係な土地が含まれる場合があります。 この問題にどのように取り組むべきですか？

14 java  ai  grid 

OUYA開発者に質問するのが早すぎないことを願っていますが、開発キットを入手したばかりで、できるだけ早くゲームを実行したいと思います！ゲームのフレームワークとしてLibGDXを使用し、OUYAでAndroidバックエンドを起動しています。私のグラフィックスがどれも表示されていないことを除いて、すべてがうまくいくようです！Box2DのDebugDrawが物理を表示しているため、何が起こっているのかしかわかりません。LibGdxのSpritebatchとOpenGL ES 2.0を使用しています。すべてがデスクトップとAndroid（電話）バックエンドで正常に機能しています。 OUYAのリソースの処理に何か問題がありますか？何が問題なのでしょうか？これは、グラフィックを/ resではなくアセットフォルダーに保存しているためでしょうか？ 編集：ここにlogcatの出力があります：http：//pastebin.com/BbPyPCcR

14 java  android  libgdx  ouya 

2D物理エンジンでは、AABBとAABBの衝突を検出し、最短の貫通ベクトルを見つけてAABBの位置に追加することでそれらを解決できます。 これを行うと、最初のAABBが2番目のAABBの外側に「プッシュ」されますが、速度/加速度の変化はまったく処理されません。 シミュレーションに重力加速度を追加すると、最初の動的AABBの速度は、2番目の静的AABBの上にある場合でも増加し続けます。最終的に、速度が大きくなりすぎて衝突が検出されなくなります（動的なAABBは静的なAABBを通過します）。 解像度後に速度をゼロに設定しようとしましたが、明らかにうまく機能せず、非現実的なシミュレーションを作成しました。 オンラインで読んだところ、位置を手動で操作して衝突を解決したり、速度が正しくなかった。私は力を実装しようとしました（今のところ、質量は「ハードコードされた」1です）： void Body::applyForce(sf::Vector2f mForce) { acceleration += mForce; } void Body::integrate(float mFrameTime) { velocity += acceleration * mFrameTime; position += velocity * mFrameTime; acceleration = {0, 0}; } 衝突の解決中に最短の貫通ベクトルを力として適用すると、動的なAABBは静的なものから「押し出され」ますが、その速度は重力のないシミュレーションでは決して低下せず、永遠に動き続けます。 「一時的な」力を適用する方法はありますか？最初のAABBを2番目のAABBから押し出し、その後AABBが衝突しなくなった時点で停止する力。 ここで利用可能なソースコード全体：https : //github.com/SuperV1234/SSVSCollision

14 collision-detection  physics  physics-engine  collision-resolution 

この質問が初めての場合は、以下の更新前の部分を最初に読んでから、この部分を読むことをお勧めします。 ただし、問題の統合は次のとおりです。 基本的に、衝突の順序と衝突グループが重要なグリッド空間分割システムを備えた衝突検出および解決エンジンがあります。一度に1つのボディを移動し、衝突を検出してから衝突を解決する必要があります。すべてのボディを一度に移動し、可能な衝突ペアを生成すると、明らかに高速になりますが、衝突の順序が尊重されないため、解像度が壊れます。一度に1つのボディを動かすと、ボディに衝突をチェックさせなければならず、^ 2の問題になります。グループをミックスに入れると、多くのボディで非常に速く非常に遅くなる理由を想像できます。 更新：私はこれに本当に一生懸命取り組みましたが、何も最適化することができませんでした。 Willによって記述された「ペインティング」の実装に成功し、グループをビットセットに変更しましたが、非常に小さなスピードアップです。 また、大きな問題を発見しました。私のエンジンは衝突順序に依存しています。 私はユニークな衝突ペア生成の実装を試みました。これは間違いなくすべてを高速化しますが、衝突の順序を破りました。 説明させてください： 私の元の設計（ペアを生成しない）で、これが起こります： 単一の体が動く 移動した後、セルを更新し、衝突したボディを取得します それが解決する必要があるボディとオーバーラップする場合、衝突を解決する つまり、ボディが移動して壁（または他のボディ）にぶつかった場合、移動したボディのみが衝突を解決し、他のボディは影響を受けません。 これが私が望む行動です。 物理エンジンでは一般的ではないことを理解していますが、レトロスタイルのゲームでは多くの利点があります。 通常のグリッド設計（一意のペアを生成）では、これが起こります： すべての体が動く すべてのボディが移動した後、すべてのセルを更新します 一意の衝突ペアを生成する 各ペアについて、衝突の検出と解決を処理します この場合、同時移動により2つのボディがオーバーラップする可能性があり、それらは同時に解決します。これにより、ボディは事実上「互いに押し合い」、複数のボディとの衝突安定性が損なわれます。 この動作は物理エンジンでは一般的ですが、私の場合は受け入れられません。 また、別の問題も発見しました。これは重大です（実際の状況では起こりそうにない場合でも）。 グループA、B、Wのボディを検討する AはWとAに衝突して解決します BはWとBに対して衝突して解決します AはBに対して何もしません BはAに対して何もしません 多くのAボディとBボディが同じセルを占有する場合があります-その場合、ボディ間で不必要な反復が多く、相互に反応してはなりません（または衝突を検出するだけで解決しない） 。 同じセルを占める100体の場合、100 ^ 100回の反復です！これは、一意のペアが生成されていないために発生しますが、一意のペアを生成できません。そうしないと、望ましくない動作が発生します。 この種の衝突エンジンを最適化する方法はありますか？ これらは尊重されなければならないガイドラインです： 衝突の順序は非常に重要です！ ボディは一度に1つずつ移動し、次に衝突を1つずつ確認し、移動後に1つずつ解決する必要があります。 ボディには3つのグループビットセットが必要です グループ：ボディが属するグループ GroupsToCheck：ボディが衝突を検出する必要があるグループ GroupsNoResolve：ボディが衝突を解決してはならないグループ 衝突を検出するだけで解決しない場合があります 事前更新： はじめに：このボトルネックを最適化する必要はないことを認識しています-エンジンは既に非常に高速です。しかし、楽しくて教育的な目的で、エンジンをさらに高速にする方法を見つけたいと思っています。 柔軟性と速度に重点を置いて、汎用C ++ 2D衝突検出/応答エンジンを作成しています。 そのアーキテクチャの非常に基本的な図を次に示します。 基本的には、メインクラスWorld所有している、の（メモリ管理）ResolverBase*、SpatialBase*およびvector<Body*>。 …

14 c++  collision-detection  performance  optimization  grid 

私は次のものを使用して画面にテキストをレンダリングしたいだけです： モノゲーム3.0 MS Visual Studio 2010 C＃エクスプレス XNAでは、非常に簡単にコンテンツパイプラインにフォントを追加できました。しかし、これはモノゲームでは当てはまらないようです。を使用Content<SpriteFont>.Load()したTTFファイルの読み込みは機能しません。XNAをインストールせずに、フォントデータを含む* .spritefontファイルまたは* .xnbファイルを生成またはダウンロードする方法はありますか？

14 xna  monogame 

そのため、正確には.NETでSharpDXを使用してDirectX開発を行っています（ただし、DirectX / C ++ APIソリューションは適用可能です）。DirectXを使用して、直交投影で線をレンダリングする最速の方法を探しています（たとえば、科学アプリの2D線画のシミュレーション）。 私がレンダリングしようとしているプロットの種類のスクリーンショットは次のとおりです。 これらの種類のプロットでは、ラインごとにアンチエイリアシング（またはフルスクリーンAAのオン/オフ）の有無に関係なく、数百万のセグメントがあり、太さが変化するラインを持つことは珍しくありません。ラインの頂点を非常に頻繁に（たとえば、20回/秒）更新し、可能な限りGPUにオフロードする必要があります。 これまで私は試しました： ソフトウェアレンダリング、たとえばGDI +は実際にはパフォーマンスの低下ではありませんが、明らかにCPUに負荷がかかります Direct2D API-GDIよりも遅く、特にアンチエイリアスがオンの場合 この方法を使用するDirect3D10 は、CPU側で頂点カラーとテッセレーションを使用してAAをエミュレートします。また遅い（プロファイルを作成し、頂点位置の計算に時間の80％が費やされる） 3番目の方法では、頂点バッファーを使用して三角形のストリップをGPUに送信し、200ミリ秒ごとに新しい頂点を更新します。100,000ラインセグメントのリフレッシュレートは約5FPSです。理想的には数百万人が必要です！ 今、私は最速の方法は、GPU、例えばジオメトリシェーダーでテッセレーションを行うことだと考えています。頂点をラインリストとして送信するか、テクスチャでパックし、ジオメトリシェーダーでアンパックしてクワッドを作成できます。または、生のポイントをピクセルシェーダーに送信し、ブレゼンハムライン描画を完全にピクセルシェーダーで実装します。私のHLSLは2006年のさびたシェーダーモデル2であるため、最新のGPUが実行できるクレイジーな機能については知りません。 質問は次のとおりです。-誰もこれを以前にやったことがありますか、試してみる提案はありますか？-ジオメトリをすばやく更新してパフォーマンスを改善するための提案はありますか（たとえば、20msごとの新しい頂点リスト）。 1月21日更新 それ以来、LineStripおよびDynamic Vertex Buffersを使用するGeometryシェーダーを使用して、上記のメソッド（3）を実装しました。現在、10万ポイントで100FPS、1,000,000ポイントで10FPSを取得しています。これは大きな改善ですが、今ではフィルレートと計算が制限されているため、他の手法やアイデアについて考えました。 ラインセグメントジオメトリのハードウェアインスタンス化はどうですか？ Sprite Batchはどうですか？ 他の（ピクセルシェーダー）指向のメソッドはどうですか？ GPUまたはCPUで効率的にカリングできますか？ あなたのコメントと提案は大歓迎です！

14 2d  directx  shaders 

ピクセルアートを拡大するアルゴリズムはたくさんあります。（私が好むHQX。個人的に、）しかし、それを拡張する任意の顕著なアルゴリズムがあるダウンは？私のゲームはの解像度で実行するように設計されていますが、低解像度でプレイする場合は、見栄えを良くしたいです。1280x720 ほとんどのピクセルアートの議論は、コンソールエミュレーターで使用するために、320x200または640x480アップスケーリングを中心にしていますが、Monkey Island Remakeのような現代の2Dゲームは、低解像度でどのように見えるのでしょうか。 もちろん、アセットの複数のバージョンを持つオプション（つまり、ミップマッピング）を無視します。

14 graphics  graphics-programming  pixel