ピクセルアートを縮小するにはどうすればよいですか？

ピクセルアートを拡大するアルゴリズムはたくさんあります。（私が好むHQX。個人的に、）しかし、それを拡張する任意の顕著なアルゴリズムがあるダウンは？私のゲームはの解像度で実行するように設計されていますが、低解像度でプレイする場合は、見栄えを良くしたいです。1280x720

ほとんどのピクセルアートの議論は、コンソールエミュレーターで使用するために、320x200または640x480アップスケーリングを中心にしていますが、Monkey Island Remakeのような現代の2Dゲームは、低解像度でどのように見えるのでしょうか。

もちろん、アセットの複数のバージョンを持つオプション（つまり、ミップマッピング）を無視します。

現在、さまざまなディスプレイサイズとアスペクト比で実行する必要があるゲームを作成していますが、それほど簡単なプロセスではありません。さらに、ピクセルアートで物事を作成していて、多くの解像度をサポートしながらピクセルアートの感覚を維持したい場合は、苦痛の世界に足を踏み入れているので、準備してください。

私の意見では、できることはいくつかあります（一部は排他的ですが、他はそうではありません）

1. 最小解像度を定義し、整数値で最も近いもののみをアップスケール（すべて）します。そうすれば、ピクセルアートの感覚を保つことができます。細部を失うことになるため、ダウンスケーリングは良い考えではないと思います。また、慎重に作成されたピクセルアートを使用する目的はすべて無効になります。サポートされている最小解像度がスプライトに対して小さすぎる場合、サポートされている最小解像度を変更するか、すべてのアセットを再描画してこの最小解像度をサポートします。

2. 画面全体をカバーするのに十分ではない解像度またはアスペクト比に遭遇した場合、アセットを損なわずにゲームを拡張します（より多くのタイルを表示します）。ただし、最小の解像度/アスペクト比でプレイできるようにゲームを作成する必要があります。

3. ゲームを延長できない場合は、画面のゲーム以外の部分を黒で塗りつぶします。上下のストライプ、左右、または黒いフレームのいずれか。これは、iPhoneアプリを拡大モードで実行するときにiPadが行うことです。これは、エミュレータでも広く使用されています。

4. ピクセルグリッドに忠実であることをあきらめます。ただし、角の鋭いピクセルアートアセットの使用を停止する必要があります。次に、バイリニア（またはプラットフォームがサポートしている場合は最適にバイキュービック）フィルタリングを使用して、アップスケール/ダウンスケールします。これは、サポートされるすべての解像度でユーザーエクスペリエンスを同様に保ちながら、画面の使用率を最大化するための最良の選択です。

私のゲームでは、オプション番号4を実行することになり、垂直方向の320ピクセル（古いAndroid 2.3）から垂直方向の1536ピクセル（2012 iPad網膜ディスプレイ）。元のアセットは、垂直方向の600ピクセルを対象としています（元はWindows PCの800x600ディスプレイ用）。後続のゲームでは、論理的な垂直解像度の方が720ピクセルになると思います。

ゲームは、バイリニアフィルタリングを使用してデバイスのネイティブ解像度にスケーリングされた、仮想600ピクセルの高仮想解像度を使用します。つまり、すべてのコード内Y座標は0（画面の上部）から600（画面の下部）になります。

水平サイズについては、最大幅は1080ピクセルで、これは最も広い16：9のアスペクト比をカバーするのに十分すぎると思います。私のx座標は中央にあるので、x = 0は画面の中心であり、x座標は左の-540から右の540になります。最も狭いディスプレイ（4：3）をサポートするために、すべてが-400から400の間に収まることを確認します

ただし、ピクセルアートの感覚を維持する必要がある場合は、オプション1と2を使用します。つまり、ピクセルアートのブロック感を維持するために整数でのみスケーリングし、ゲームの量が見えるように設計することを意味しますタイルは固定されておらず、任意の画面解像度/アスペクト比に適応できます。

だから、あなたの質問に答える（しない）ために。ピクセルアートの縮小は非常に悪い考えだと思うので、そうすべきではありません。さまざまな画面解像度をサポートする方法は他にもあり、慎重に作成したアートを単に屠殺するよりも優れた結果が得られます。

開発時に縮小バージョンを実際に生成し、それらをリソースとしてゲームに直接含めることを検討してください。Photoshopを使用するか、見つけたツールを使用して好きなものを作成します。次に、ゲームに現在の解像度に適した適切なアートセットを動的に選択させます。

これを行う理由はいくつかあります...

処理作業を節約

実行時にプログラムでスケール変更した場合、ソフトウェアはおそらくアートワークを作成してキャッシュします。では、縮小版をアートアセットバンドルに含めるだけではどうでしょうか。ダウンロードが必要以上に大きくなったとしても、CPUの負荷やディスクの書き込みなどは節約できると思います。

より優れた芸術的コントロール

自分でアートのスケールを変更すると、最終的な外観をより細かく制御できます。少し縮小しても違いはないかもしれませんが、解像度をはるかに低くした場合、最終的な外観をより芸術的に制御したいと思うかもしれません。たとえば、特定のキャラクターの目を強調する必要がある場合、効果を維持するために目をあまり縮小しないで低解像度バージョンを実際に描画することができます-プログラムによるスケーリングではできません。

動的スケーリングは完全ではありません

動的なスケーリングでは機能しない、独特の芸術的な決定を下すことができます。たとえば、画像の周りに境界線、輪郭、またはハイライトを配置するとします。より高い解像度で表示した場合、これは問題なく見えるかもしれませんが、縮小版は濁っているか、完全に効果を失うかもしれません。ただし、手作業で行う場合は、各サイズに効果を具体的に適用して、影響を保持することができます。

他の考え

また、見つかった場所で使用される解像度固有のリソースのセットと、解像度固有のバージョンが見つからない場合に動的にスケーリングされる汎用セットを使用して、ハイブリッドアプローチを実行することもできます。これは、Androidプラットフォームの仕組みに少し似ています。これに関するいくつかの情報はhttp://developer.android.com/guide/practices/screens_support.htmlにあります

ギャップを埋めるために新しい（および場合によっては誤った）情報を作成する必要はなく、破棄する情報を選択しているため、サイズ変更はサイズ変更よりも簡単です。そのことを念頭に置いて、おそらくここで特別なものは必要なく、画像処理の領域からのほとんどの標準リサンプリングアルゴリズムは、画像の縮小にかなりうまく機能します：バイリニア、ガウス、ランチョスなど

特にLanczosは、複数のピクセルを1つに結合するときに失われる細部を保存する可能性があるため、画像を鮮明にするため、興味深い選択肢です。明らかに、これには、不要なアーティファクトが潜在的に導入されるという犠牲が伴います。

ここでいくつかの視覚的な比較：https : //gis.stackexchange.com/questions/10931/what-is-lanczos-resampling-useful-for-in-a-spatial-context