5

複数の画面をサポートするかどうかという質問は非常によく聞かれますが、ゲーム開発 (ヒットボックス、衝突チェックなど) に関する議論はあまり見られませんでした。

現在、私のゲームは「互換モード」で実行されており、アップスケーリングが原因で、ハイエンド デバイスでのビジュアルが非常に悪くなります。ゲームのグラフィックスをすべての画面サイズで見栄えよくするために他の人が行ったことについて、ヒントや推奨事項を探しています。

開発者は各リソース (中密度と高密度) の 2 つのコピーを含めますか? それとも高密度リソースは低密度デバイス用に単純に縮小されますか?

密度に依存しないピクセルが計算に使用されていますか?

4

2 に答える 2

2

開発者は各リソース (中密度と高密度) の 2 つのコピーを含めますか? それとも高密度リソースは低密度デバイス用に単純に縮小されますか?

これは物事を処理する1つの方法です。私は次のことが行われているのを見てきました:

  1. サポートしたい各解像度のビットマップを含めます
  2. サポートしたい最高の解像度のビットマップを含め、他の解像度の場合は縮小します。
    • タイルシート (つまり、大きなビットマップ内の複数の小さなビットマップ) を使用する場合、バイリニア フィルタリング、つまりエッジ ピクセルと隣接するアセットのブレンドに注意する必要があります。これが発生すると、アセットにライン/アーティファクトが表示されます。この問題に関する議論がhttp://developer.anscamobile.com/forum/2011/06/03/lines-between-my-tilesにあります。
  3. サポートする最高解像度のベクター グラフィックスを使用します。

方法 2. または 3. を使用する場合、これが私が処理する方法です。

  • 960 x 1600 の画面サイズを対象とするアセットを作成します。
  • 480 x 800 - 半分に拡大
  • 320 x 400 - 3 分の 1 に拡大

これにより、今後の計算に必要な画面密度の値が得られます。

私は方法3を好みます。

現在、ディスクから .svg アセットをロードし、ステージの「ロード」部分で「ビットマップに描画」するアイソメトリック 2D ゲーム エンジンに取り組んでいます。これにより、ディスク (.svg) 上のサイズが小さくなり、ゲームの実行中にパフォーマンス (ビットマップ) が高速になるという利点が得られます。

ワークフローは次のとおりです。

  1. レベルに必要なゲーム アセットを解析する
  2. 関連する .svg アセットをディスクから読み込む
  3. .svg コンテンツをビットマップに描画します
  4. 読み込んだ.svgを捨てる
  5. すべてのアセットについて繰り返します
  6. 開始レベル

密度に依存しないピクセルが計算に使用されていますか?

はい、次のように使用します。

sprite.x = new_x_position * screen_density;
于 2012-02-29T18:02:54.820 に答える
0

多くの開発者は、リソースの2つのコピーを含めるか、最初の実行時に高解像度のコピーをダウンロードします。初回実行時にダウンロードする場合は、Androidリソースマネージャーを使用していません。

于 2011-04-19T14:22:54.380 に答える