私は最近、悪名高い LunarLander と同様のアプローチを使用して、最初の Android ゲームを実装しようとしています。私はゲーム エンジンの助けを借りずに自分でグラフィックをレンダリングしています。これは、これまでの作業の中で最も複雑な部分のようです。
問題
画面の幅を決定し、その情報をアルゴリズムに転送します。このアルゴリズムは、幅とその他の余白の値 (以下を参照) を考慮して、水平方向にレンダリングできる画像の最大数を決定しますcalculateMaxBeadsInWidth()。ただし、数学はアルゴリズムによって計算された値と一致していないようです。X基本的には、表示できる画像の量だけを判断していますが、実際X + 2には画面に簡単に画像を表示できます。
計算
800 pixels画面の実際の幅がで、画像の幅が であることを示す多くのデバッグ出力を解析しました44 pixels。したがって、余白が100 pixels(50 pixels左端と50 pixels右端にある) とすれば、それはそのまま残し700 pixelsます。ではfloor(700 / 44) = 15、15 枚の画像のみを表示します。しかし、明らかにもっと多くのスペースがあります（写真を参照）!!
コード
私のアルゴリズム:
private int calculateMaxBeadsInWidth() {
float eff_width = screenWidth - (BOARD_MARGIN_HORIZONTAL * 2);
return (int) (eff_width / bead_width);
}
BOARD_MARGIN_HORIZONTALの値はであることに注意してください50.0f。
いくつかの写真
これは私のアルゴリズムによって生成されているものです:
ただし、ご覧のとおり、線の端 (右側) に向かって少なくとも 2 つのビーズを簡単に合わせることができることは明らかです。たとえば、この図は、1 行のビーズの数を、アルゴリズムが生成するビーズの数よりも 2 つ多くハードコーディングするとどうなるかを示しています。
これは、余白が赤い線で詳細に示されている画像です。ご覧のとおり、まだ十分なスペースがあります。
補足情報
このアプリケーションを Google Nexus 7 でテストしています。
getResources().getDisplayMetrics().widthPixels;画面の幅を取得するために使用しています。問題はここにあるのではないでしょうか？
私の質問
結果に影響を与えている、ここで考慮していない解像度の値はありますか? なぜこれがそれほど不正確に計算されているのでしょうか?
さらに情報が必要な場合は、喜んで提供します。どんな助けでも大歓迎です!
