1

~10 画面の Android ゲームのアート サイズを指定しようとしています。ゲームを API 8 以降で、「小」以外のすべてのサイズの画面で実行したい。

API 8 を使用しているため、古い「画面の 4 つのカテゴリ」機能を使用しています。サポートする予定です。

  • 通常 (480 x 320、最大 640 x 480)
  • 大 (640 x 480、最大 960 x 720)
  • 特大 (960 x 720、最大 1920 x 1200)

1920x1200 の png ファイルは ~4.1MB です。つまり、そのうちの 10 個は 41 MB であり、50 MB のアプリ サイズ制限 (Play ストア) をほぼ超えています。

3 つの質問: 1. ゲーム画面の詳細なアートワークをどのようにサポートしていますか? 背景には淡い色の 9 パッチ png ファイルを使用する必要がありますか? それとも、すべてのアートを 960x720 のサイズで保存し、大画面と通常画面用に Android でサイズ変更できるようにすることは可能ですか? このサイズのバックグラウンド ファイルが 10 個あると、合計で約 15 MB になり、残りは 35 MB になります。

png の代わりに jpg を使用するとどうなりますか? どのくらいの品質が失われますか? ダウンサイジングしかないので、これでいいはずですよね？960x720 の 10 jpg はわずか 4.3 MB です。

  1. Android にサイズ変更を許可する場合、960x720 の 4:3 とは異なる縦横比の画面をサポートするにはどうすればよいですか? レイアウト XML で指定する方法はありますか? (そして、960x720 より大きい超大画面の場合は、drawable を画面の中央に配置するだけで、まったく引き伸ばさないでください)?

  2. 画面の DPI 解像度はこれをまったく考慮していませんか? DPI は、アイコンやボタンのように、異なる解像度の画面で何かをほぼ同じサイズにしたい場合にのみ考慮する必要があります。正しい？

これは、よく知られているパターンまたはテンプレートに従うことで解決された問題のようです。他の人はどのようにそれをしましたか？インストール後に膨大な量のダウンロード (回避したい) または 9 つのパッチ バックグラウンドを使用している人はいますか?

アドバイスをよろしくお願いします。ここでいくつかの用語で検索し、探しているものが見つからずに過去の約 25 の回答を調べました。

ピーター

4

1 に答える 1

1

Resurrecting the dead (thread): one way of doing things could be to provide just one set of bitmaps and do the scaling yourself. You can either provide large bitmaps and scale them down, or provide middle of the road bitmaps and scale them up (for large screens) and down (for smaller sizes).

The benefits of the former are that your art looks great on large screens and you are a bit more future proof (if you provide for this in your code). The downside is that you could (and actually likely will) run into Out Of Memory/Exceeding VM errors when decoding/loading these bitmaps on lower-end devices, even when doing it carefully. So I usually go for the second approach.

Scaling up can be done a number of ways, but one is to just load in the bmp at it's default size (use getResources().openRawResource(id) or BitmapFactory.decodeResource(etc) or even better use inputstreams or [according to some the best method] load/create using the FileDescriptor methods) and then scale it either by creating another bmp using createScaledBitmap() or if drawing to a canvas draw it to a destination Rectangle (better memory wise). For scaling down you can either use BitmapOptions like .inScaled or, again, use a smaller destination Rect in your canvas drawcall.

Doing it this way is way better and (for a game) faster than letting Android scale for you using those buckets (hdpi etc) and uses less memory if done right.

But beware as some bitmap loading methods are a bit buggy and create 'the bmp is too big for the VM' errors. Also learn to dispose of your bmps properly; a lot of people and Google/Googlers say Android does this and you don't have to set your bmps to null and recycle() them, but so far I've found that you do. Another caveat is to set the proper options (filtering/antialiasing etc) to prevent blurry bmps. And take care of un-optimal color/format/dpi settings on BitmapOptions/canvasses/SurfaceViews and even windows.

There's much more, but this should help anyone get started.

于 2014-02-26T02:36:02.820 に答える