サブピクセル表現｜1px未満の動きと実装

この記事では、まずディスプレイの「サブピクセル（副画素）」と、ドット絵やゲームで1px未満の動きに見せる「サブピクセル表現」をきちんと切り分けます。
液晶のRGB副画素を使う文字表示の話と、作画で中間色を置く話、実装で小数座標や描画スナップを使う話は、同じ名前でも中身が別物です。
そのうえで、作画なら輪郭を動かさず中間色だけでずらして見せる方法、アニメなら差分絵で呼吸や重心移動を作る方法、実装なら float 座標＋スナップやバイリニア補間をどう使い分けるかを、具体例つきで整理します。
16x16の円や顔アイコンで“0.5px右へ”を見せる比較や、32x32歩行スプライトの再現図も交えながら、見た目が成立する境界を確かめていきます。
色フリンジ、ぼやけ、ジャダーは、低解像度の絵ほどごまかしが効きません。
先に失敗の出方を知っておくと、Asepriteでの差分作画もUnityでの Pixel Perfect Camera 設定も、何を守れば絵が崩れないのかがはっきり見えてきます。

サブピクセル表現とは？まず2つの意味を分けて理解する

用語の整理: 副画素/Rendering/表現技法

まず、同じ「サブピクセル」という言葉で別の話が混ざりやすいので、ここを切り分けます。
サブピクセル（subpixel, 副画素）は、ディスプレイの1ピクセルを構成する赤・緑・青の小さな発光要素のことです。
液晶の説明では、この副画素が横に並ぶRGBストライプを基本例として扱うことが多く、ここでの話題は表示装置そのものに属します。

次に、サブピクセルレンダリング（Subpixel rendering）は、そのRGB副画素を個別に利用して文字やUIの輪郭を細かく見せる表示技術です。
小さい文字が少しでもシャープに読めるよう、1ピクセル単位ではなく副画素単位でエッジを調整する発想だと捉えるとつかみやすいのが利点です。
WindowsのClearTypeを思い浮かべると近く、画像そのものに「半ピクセルの絵」を描き込む技法ではありません。

一方で、ドット絵の文脈でよく言うサブピクセルアニメーション（pixel-art技法）は、物理的な副画素を操作しているわけではありません。
中間色、アンチエイリアス、差分スプライト、内部色の変化などを使って、1px未満の移動や重心変化が起きたように見せる錯視ベースの画作りです。
こちらは表示技術ではなく、作画とゲーム実装の話です。

この切り分けを曖昧にすると、話が一気にこんがらがります。
小サイズのUI文字と16x16アイコンを同じ画面に並べて設計するとき、私は前者をOSやフォント描画系の処理に任せ、後者は画像側で錯視を作る、という流れで整理します。
図にすると「文字は表示技術の領域」「アイコンは作画技法の領域」と左右に分ける形がいちばん誤解がありません。
同じ“サブピクセル”でも、担当する層が違うからです。

1px=3サブピクセルが意味すること

ディスプレイの基本説明では、1pxは3つのRGBサブピクセルで構成されると考えます。
ここから、横方向により細かい位置情報を使えるので、文字の縦線や斜線を1ピクセル刻みより細かく見せられる、というのがサブピクセルレンダリングの骨格です。
小さいフォントで「黒か白か」だけだとギザつく場面でも、副画素を分けて使えば見かけの解像感を高められます。

ただし、ここで得られるのは表示上の細かさであって、画像データのピクセル数が増えるわけではありません。
たとえば8x8のスプライト画像が、保存時点で8.5x8.0になるわけではない、ということです。
副画素を使う話はディスプレイ側の都合で成立していて、絵のデータ構造そのものとは別です。

ドット絵の「0.5px右に動いた感じ」を作るときは、考え方がまったく違います。
8x8の黒いドットの塊を右へ1px動かすと、一気に飛びすぎて見える場面があります。
そういうとき、Beforeでは右端が真っ黒な1pxの縦線で止まっていたものを、Afterではその右端の黒1pxを中間灰の #808080 に置き換え、さらに一つ内側に暗い色の1pxを足します。
輪郭を丸ごと右へ送るのではなく、右側に“少しだけ光が回り込んだ”“重心がにじんだ”ような見え方を作るわけです。
結果として、実際には整数グリッドのままなのに、目には「半歩だけ右へ寄った」ように映ります。

このとき使っているのはRGB副画素の独立制御ではなく、人間の目が輪郭と濃度差を位置として解釈する性質です。
だから、ピクセルアートのサブピクセル表現は表示装置の仕組みを借りる技術ではなく、あくまで絵作りのテクニックとして理解したほうが正確です。

どの話題でどの用語を使うか

実務では、ここを言い分けるだけで会話の精度が上がります。
ディスプレイやフォント描画の話なら「サブピクセルレンダリング」と呼ぶのが適切です。
RGB/BGRの並び、画面回転、特殊配列、色フリンジの話題が出てきたら、それは表示技術側の用語だと考えてまず外しません。
副画素の並びが違えば最適な描画も変わるので、こちらは配列依存です。

反対に、ピクセルアートで「0.5px動いたように見せる」「呼吸で胸だけふくらんだ感じを出す」「輪郭は止めたまま内部色だけ変えて重心をずらす」といった話は、サブピクセル表現またはサブピクセルアニメーションと呼ぶと誤解が少なくなります。
ここではRGB/BGR配列を気にする必要はありません。
絵として成立するかどうかが論点であり、使っているのは副画素ではなく、明度差とエッジ処理の設計だからです。

ゲーム実装まで含めるなら、さらに「小数座標で管理する」「描画時だけスナップする」という別の層も出てきます。
たとえばUnityのPixel Perfect Cameraで Assets PPU を16にそろえた場合、1ピクセルに対応する移動量は 1/16、つまり 0.0625 ワールドユニットです。
ここでの“サブピクセル”は、あくまで座標精度の話です。
作画で灰色を置く話とも、LCDの副画素を使う話とも混ぜないほうが整理できます。
呼び方を揃えるなら、私は次の3つに分けます。
表示装置の副画素を使うなら「サブピクセルレンダリング」。
ドット絵の錯視による半歩表現なら「サブピクセル表現」または「サブピクセルアニメーション」。
ゲーム内部でfloat座標を持って描画時に丸めるなら「小数座標」や「描画スナップ」です。
この区別が入るだけで、フォントのにじみ対策と、16x16アイコンの差分作画と、カメラのジャダー対策を同じ箱に入れずに済みます。

• Unity の 2D Pixel Perfect（Pixel Perfect Camera）パッケージの設定例や用語（Reference Resolution / Pixel Snapping / Assets PPU）については公式ドキュメントが参考になります。
• FreeType の LCD レンダリングやフィルタ挙動に関する実装事項は FreeType の公式資料に要点がまとまっています。

これら公式ドキュメントを参照することで、表示側（レンダラ／フォントライブラリ）と画像側（スプライト／素材）とでどのように役割分担すべきかがより明確になります。
もうひとつ見逃せないのがブレンディングです。
LCDレンダリングは色チャンネルごとの値を細かくいじるので、ガンマが絡むと色のにじみが目立ちます。
線形空間でアルファブレンドしてから表示ガンマへ戻す流れを取ると、エッジの色アーティファクトが抑えやすくなります。
ここは見た目に直結する部分で、フィルタだけ整えても合成側が雑だと、細い文字ほど縁が汚れて見えます。

実際に比較すると差ははっきり出ます。
私は黒地に白文字を置いたUIで、OS標準のサブピクセルON、グレイスケールAA、AAなしの3種類を並べてキャプチャする構成をよく考えます。
AAなしは輪郭がギザギザになり、グレイスケールAAは色は出ない代わりに少し柔らかく見えます。
サブピクセルONは縦線が締まって読める一方、拡大すると左右に赤や青の気配が見えます。
等倍では可読性の利益が勝ち、拡大確認では副作用が見える、という対比がいちばん本質に近いです。

なお、実装の自由度という背景では、Microsoft系のサブピクセル関連特許が 2019年7月30日 に満了しています。
このため、現在はサブピクセル描画そのものを避ける理由が特許回避一択だった時代より整理しやすくなっています。
技術上の論点は、いまでは配列適合と色フリンジ制御のほうへ移っています。

配列不一致と色フリンジ

サブピクセルレンダリングの弱点は、副画素の並びを前提にした最適化である以上、その前提が外れると色が漏れる ことです。
典型例は RGB と BGR の違いです。
レンダラが RGB ストライプだと思って左側に赤、右側に青が来るようにエッジを作ったのに、実際のパネルが BGR なら左右の色が逆転します。
細い縦線の左にうっすら赤、右に青が見えるはずの設計が、BGR では左が青、右が赤に見えます。
文字の縁取りが「逆色になる」という現象です。

とくに分かりやすいのは、細い垂直線を 0.5px 横へずらしたように見せる 場面です。
副画素を使って線の重心を右へ寄せると、RGB 配列では左側に赤み、右側に青みが残ることがあります。
これは線そのものが赤青に塗られたのではなく、R/G/B を別々の位置で点灯させた副作用です。
ところが BGR 配列では同じロジックが逆向きに働くので、今度は左に青、右に赤が現れます。
拡大表示すると一目で分かる種類のズレです。

画面回転でも同じ問題が起きます。
横方向のRGBストライプを前提にした最適化は、ディスプレイを90度回転させた瞬間に、物理的には縦方向へ並んだ副画素に対して横方向レンダリングをしている状態になります。
すると、得たいはずの「横方向の精細さ」ではなく、色付きのにじみだけが目立ちます。
ノートPCを縦置きしたときや、回転可能な液晶で表示方向だけ変えたときに違和感が出るのはこのためです。

一部のパネルでは副画素形状や並びが、従来の横一列 RGB ストライプとは異なることがあり得ます。
機種や世代によって配列や副画素の形状が多様なため、サブピクセルレンダリングを適用する際は表示先の配列を確認すると安全です。
この種のパネルでは、グレイスケールAAのほうが結果として安定することがあります。
サブピクセルレンダリングは万能の高精細化ではなく、物理配列と描画ロジックが一致しているときに最も効果を発揮する最適化だと考えてください。
一部の最新パネルでは副画素の形状や配列が従来の横一列RGBストライプとは異なる場合があります。
機種や世代による差が大きいため、サブピクセルレンダリングを適用する際は表示先の配列を確認することを推奨します。

画像化・回転でのNGパターン

実務で避けたいのは、サブピクセルレンダリング済みの文字を完成画像として焼き込むこと です。
表示時に最適化される前提の処理を、画像として固定してしまうと、その瞬間に配列情報が失われます。
たとえば RGB 前提で描かれた文字列をPNGにして配布し、受け手の画面が BGR だったり、縦回転だったりすると、文字の左右に赤青のにじみがそのまま見えます。
表示エンジンが再調整する余地がないからです。

回転も危険です。
LCD向けに作られた文字画像を90度回すと、本来は横方向にだけ意味があった色の偏りが、そのまま上下方向の縁取りになります。
縮小でも同じで、赤・緑・青に分かれた細い情報を再サンプリングすると、想定していない色の混ざり方になります。
元の文字が小さいほど、縮小後は「輪郭が少し柔らかい」では済まず、赤青の濁りとして残ります。
UI素材として一度画像化した時点で、サブピクセル前提のメリットはほぼ失われ、副作用だけが残りやすくなります。

このため、文字やアイコンを素材として持ち回す場面では、サブピクセルレンダリング済みのビットマップを中間成果物にしないのが定石です。
配布用の画像にするならグレイスケールAAか、用途によってはAAなしのほうが安全です。
サブピクセル処理は、最終表示先のパネル配列が確定している段階で適用する のが筋です。
OSやフォントレンダラが画面直前で行うぶんには理にかなっていますが、アセットとして保存した瞬間に前提が崩れます。

ここはドット絵の文脈ともつながります。
ピクセルアートで「半ピクセルっぽく見せる」ために中間色を描き込むのは画像そのものの設計なので、回転や縮小で崩れてもそれは通常のリサンプリング問題です。
サブピクセルレンダリング済み文字の崩れ方はそれとは別で、物理副画素を前提にした色ずらしを、配列不明の画像へ封じ込めたこと が原因です。
同じ「にじみ」でも、発生源が違います。
ここを混同しないだけで、文字は表示時に処理し、ドット絵は画像として設計する、という役割分担がきれいに見えてきます。

ピクセルアートで1ドット未満の動きを作る基本手法

（以下の節では、可能な限り具体的な数値・例を示して説明します）

中間色で輪郭を“傾ける”

1ドット未満の動きを作るとき、いちばん再現しやすいのは輪郭そのものを移動せず、見た目の重心だけを寄せるやり方です。
小さなスプライトでは、輪郭を1px動かした瞬間に「動いた」というより「跳ねた」と見えます。
そこで使うのが、中間色で輪郭の強さを片側だけ弱め、反対側の内側に暗色を足して、形がそちらへ寄ったように見せる方法です。

具体例として、16x16の円を2フレームで揺らす場面を考えます。
1フレーム目は通常の黒輪郭の円、2フレーム目では右端の黒輪郭1pxを中間色に置き換えます。
それだけだと輪郭が薄くなっただけに見えるので、円の内側右寄りに暗色1pxを追加して密度を戻します。
すると輪郭線の存在感は半歩ぶん右へ溶け、内側の暗さが形の芯を右へ引っ張るので、見た目としては“右へ0.5pxほど寄った”ように感じます。
実ドットは整数座標のままでも、視線は輪郭のコントラスト差から位置を判断するので、この錯視が成立します。

この手法は顔アイコンでも効きます。
16x16の顔を作ると、輪郭を触るより先に、瞳の白ハイライト1pxを上下に1pxだけ入れ替えたほうが、視線の揺れとして自然に見えることがよくあります。
私も小さな会話アイコンを作るとき、目玉そのものを動かさず、ハイライトだけを上下させる設計をよく入れます。
輪郭を保ったまま「視線が落ち着かない」「少し考えている」といった気配が出るからです。
1px未満の移動は、厳密な座標の話ではなく、どこに視線が引かれるかを制御する作業だと考えると組み立てやすくなります。

Before/Afterの比較図を作るなら、2フレームを左右に並べて、右端輪郭の置換部分と内側に足した暗色1pxだけを色枠で示すと差分が一目で伝わります。
変えたドット数が少ないほど、この手法の効果は理解されやすくなります。

AAでにじませる疑似移動

AAを使った疑似移動は、輪郭の位置を変えるのではなく、エッジの角度だけを少し変えて見せる方法です。
とくに斜め線や階段状エッジでは、角の1pxをどう処理するかで、進行方向に傾いた印象が出ます。
ドット絵のAAは単に滑らかにするためだけでなく、運動方向を示すための“圧力”としても使えます。

たとえば、右へ進む丸みのある物体や靴先の斜めエッジがあるなら、階段状になっている角のうち、進行方向側の角だけを中間色1pxに置き換えると、輪郭がそちらへにじんだように見えます。
黒→中間色→背景色という順でコントラストが緩むため、エッジが柔らかく倒れ込み、静止画のままでも“次のフレームで右へ行きそう”という予感が出ます。
反対側はそのまま締めておくと、移動方向の偏りが明確になります。

この差は歩行スプライトで比べると分かりやすいのが利点です。
32x32の歩行スプライトで、靴先のAAだけを変えた2フレームと、アウトラインごと1px前へ出した2フレームを並べると、前者は接地感を残したまま重心だけが進み、後者は足先が浮いて見えやすくなります。
実際に並べると、アウトライン移動のほうはフレーム境界で飛び感が出ます。
靴先のAA変更だけなら、足裏がまだ地面に吸いついているように見えるので、低フレームの歩行でも粘りが残ります。

ここでのコツは、AAを線全体に広げないことです。
全部をぼかすと輪郭が眠くなります。
変えるのは角の1px、長くても2pxまでにとどめると、元のピクセル感を維持したまま方向だけを示せます。
比較図では、左右に並べた2フレームのうち、角の中間色化した1pxだけを強調表示すると、「どこをいじると飛ばずに前進感が出るのか」が説明しやすくなります。

影・ハイライトだけをずらす

物体が本当に動かなくても、光の当たり方が変われば、見た目の質量は動いているように感じます。
そこで有効なのが、影とハイライトだけを反対方向へずらす手法です。
輪郭が固定されたままでも、内部の明暗が移ると、表面が呼吸しているように見えます。

丸い頬、胸元、スライム、金属球のような形では、ハイライト1pxを光源方向へ寄せ、影を反対方向へ1pxずらすだけで、体積の芯がわずかに移動した印象になります。
呼吸や鼓動の表現ではこの差が効きます。
フレーム1で中央寄りに置いたハイライトを、フレーム2では少し上へ、同時に下側の影を1pxだけ広げると、内部圧がふっと上がったように見えます。
実際には外形が変わっていないので、アニメ全体は安定したまま、表情だけが動きます。

小さな顔アイコンの瞳ハイライトも同じ発想です。
白1pxを上に置くか下に置くかだけで、目線の揺れ、まばたき前の溜め、感情の落ち着かなさが出せます。
黒目を丸ごと動かすと視線が跳びますが、ハイライトだけなら“目の水分が揺れた”ような自然な揺らぎになります。
16x16前後のサイズでは、このくらいの差分のほうが、輪郭を動かすより説得力があります。

この手法の比較図は、2フレームを左右に置き、ハイライトの移動先と影の移動先を別色で囲うと伝わります。
差分箇所が内部に集中しているので、読者にも「外形ゼロ変更でここまで印象が動くのか」が伝わりやすくなります。

輪郭固定・内部だけ動かす

微振動や布の揺れは、外形まで揺らすとノイズに見えがちです。
とくに髪先や服のシルエットを毎フレーム触ると、揺れというより輪郭の崩れになります。
そこで、輪郭の位置や形状をフレーム間でほとんど変えず、内部の明暗だけを入れ替える構成が効きます。

髪の束なら、外周の線はそのままにして、内側の暗い筋を1pxずつ左右に送ります。
服のシワなら、暗部を1px押し出し、その隣の中間色を元位置へ戻す、という交換を2〜4フレームで回します。
これで布が震えている、風を受けて面がわずかにねじれている、といった印象が出ます。
外形が固定されているぶん、キャラクター全体の安定感は保たれ、待機モーションにも入れ込みやすい構造です。

私が待機アニメを組むときは、髪や袖の先端を大きく振る前に、まず内部の明暗だけで空気の動きを作ることが多いです。
2フレームでも成立しますが、3フレームや4フレームにすると、明部が流れて暗部が追う順番を作れるので、機械的な点滅から抜けられます。
ここで輪郭を1pxでも動かすと、一気に別のモーションになります。
逆に内部だけなら、静止姿勢の情報を壊さずに、止まりきっていない感じだけを足せます。

Before/Afterの見せ方としては、左右の2フレームを並べ、内部で入れ替えた明暗ドットだけをハイライトすると効果的です。
輪郭に差分がないことも同時に見せると、この手法の意図が明確になります。

少色パレットでの代替策

中間色やAAの話をすると、多色パレット前提に見えますが、少色でも打てる手はあります。
3色パレットなら、厳密な中間色がなくても、明度差の近い色を“仮の中間”として使うだけで、それなりに傾きは作れます。
たとえば黒輪郭と明色しかない場面でも、内部に使っている暗色を輪郭の一部へ回し、元の位置に点描で密度を補うと、完全な中間色ほど滑らかではなくても重心移動の錯視は出せます。

極端に色が少ない場合は、1pxの置換だけで足りないこともあります。
そのときは、単色の中間を探すのではなく、1pxごとの点描で平均明度を作る発想に切り替えると組み立てやすくなります。
黒と明色しかないなら、黒1・空き1の並びで“薄く見える帯”を作り、フレームを切り替えて位置を入れ替えることで、エッジの強さを変えられます。
静止画では粗く見えても、2フレームで交互にすると脳内で平均化され、半歩ぶん寄ったような印象になります。

ただし、極少色ではこの効果そのものが弱くなります。
輪郭の強さを段階的にずらす材料が足りないからです。
2色に近づくほど、「0.5px寄った」ではなく「ある・ない」の切り替えになり、錯視の幅が狭くなります。
そういう場面では、輪郭の半歩移動を無理に狙うより、ハイライト移動や内部明暗の交換に比重を移したほうがまとまりやすくなります。

図版にするなら、各手法とも2フレームを左右に並べ、差分ドットを色付きで示す構成がいちばん伝わります。
中間色置換、AAの角変更、ハイライト移動、内部明暗の交換は、どれもどこを1px変えたかが分かれば理解できる技法です。
説明もその差分に沿って行うと、読者が自分のスプライトへ移植しやすくなります。

ゲーム実装でのサブピクセル移動と見た目の両立

float座標と描画スナップ

ゲーム実装では、移動そのものと見た目の表示を分けて考えると整理できます。
基本は、物理や当たり判定、追従処理では float座標 を保持し、画面へ出す直前だけ整数ピクセルへ丸める方法です。
こうしておくと、速度が 1px 未満でも内部では連続的に進み、衝突判定や加速度も破綻しません。
その一方で、表示はドットの格子に吸着するので、ピクセルアート特有の輪郭の硬さを保てます。

たとえば 32x32 のキャラを 0.5px/フレームで動かすなら、論理座標は 0.5 刻みで進めます。
描画座標だけを整数化すると、見た目は隔フレームで 1px 動く形になります。
これは不自然というより、ピクセル格子へ正しく着地した結果です。
サブピクセル移動の要点は、この「内部は滑らか、表示は整数」という二層構造にあります。

疑似コードで書くと、形はとても単純です。

struct Actor {
    float x, y;      // 論理座標
    float vx, vy;    // 速度
};

void update(Actor& a) {
    a.x += a.vx;
    a.y += a.vy;
}

void draw(const Actor& a, const Camera& cam) {
    float screenX = a.x - cam.x;
    float screenY = a.y - cam.y;

    int pixelX = round(screenX); // または floor
    int pixelY = round(screenY);

    drawSprite(a.sprite, pixelX, pixelY);
}

ここで気をつけたいのは、round と floor の違いです。
floor は常に切り捨てるので、移動方向によって見た目が片側へ寄りやすくなります。
round は最も近い整数へ寄せるため、体感では揺れが少ない場面が多いです。
ただし、エンジン側の丸め規則や .5 の扱いまで含めて統一しないと、スプライトごとに微妙なズレが出ます。
実装のどこか一箇所だけ floor になっている、といった状態がいちばん危険です。

私が組むときは、更新処理では一切丸めず、ワールド座標からスクリーン座標へ変換した直後に一度だけ丸めるようにしています。
途中で何度も整数化すると、0.25 ずつ積み上がるはずの移動が消えたり跳ねたりして、見た目だけでなく追従カメラの挙動まで崩れます。

カメラ小数移動の揺れ対策

サブピクセル移動で最初に崩れやすいのは、プレイヤー自身よりカメラです。
キャラは整数スナップしているのに、カメラだけが小数で追いかける構成だと、背景やタイル全体がフレームごとに半端な位置へずれて見えます。
これがいわゆるジャダーの温床です。

対策は明快で、画面座標変換の直前にカメラも整数スナップすることです。
あるいは、基準解像度に対して 整数スケール × 整数オフセット の範囲にカメラを閉じ込めます。
つまり、ワールド内では小数で追従していても、実際に画面へ投影する瞬間にはピクセル格子へ着地させます。

void draw(const Actor& a, const Camera& cam) {
    int camPixelX = round(cam.x);
    int camPixelY = round(cam.y);

    int pixelX = round(a.x) - camPixelX;
    int pixelY = round(a.y) - camPixelY;

    drawSprite(a.sprite, pixelX, pixelY);
}

この順番にすると、キャラとカメラが同じルールで丸められるので、相対位置が安定します。
Unityの 2D Pixel Perfect でも考え方は同じで、Reference Resolution、Assets PPU、Pixel Snapping を揃えたうえで、ピクセル単位の移動へ落とし込む設計が軸になります。
Assets PPU を 16 にしたなら、ワールド上の 1px は 1/16、つまり 0.0625 ワールドユニットです。
移動量やスナップ幅をこの倍数へ合わせると、タイルや当たり判定の基準と表示が噛み合います。

静止画の比較でも、この差ははっきり出ます。
私が見比べたいと思っているのは、カメラだけを小数移動にした画と、スプライトまで小数描画にしてしまった画の違いです。
前者は背景やタイル面に細かな揺れが乗る一方で、キャラ自体の輪郭はまだ保たれます。
後者はキャラのエッジまでソフト化して、ドットの角が溶けたように見えます。
動かす前の静止画でも、その差は十分に読み取れます。

差分スプライトの設計

表示を整数ピクセルへ固定すると、0.5px/フレームのような遅い移動は「止まるフレーム」と「1px 動くフレーム」が交互に出ます。
ここで役立つのが 差分スプライト です。
位置そのものは整数のままでも、見た目だけ中間状態を挟めば、半歩だけ進んだ印象を作れます。

32x32 キャラを 0.5px/フレームで右へ動かす例なら、論理座標は 100.0 → 100.5 → 101.0 と進みます。
表示座標は 100 → 100 → 101 になりやすいので、100.5 のフレームでは「右へ半歩寄った見え方」の差分絵を表示します。
実際の座標は動かしていないのに、輪郭内の明暗や足の接地感が少し前へ寄るだけで、停止には見えません。

この方式は、アニメとしての中割りをゲーム側で使い分ける発想です。たとえば次のように組めます。

void drawActor(const Actor& a) {
    int pixelX = (int)roundf(a.x);
    float frac = a.x - floorf(a.x); // 0.0 ～ 0.999...

    const Sprite& spriteToDraw = (frac >= 0.25f && frac < 0.75f)
        ? a.halfStepSprite   // 0.5px相当の差分絵
        : a.baseSprite;

    drawSprite(spriteToDraw, pixelX, (int)roundf(a.y));
}

差分スプライトの作り方はいくつかありますが、考え方が分かりやすいのは 3x 解像度で保持して 1x に落とす 発想です。
3 倍の内部グリッドで位置を考えると、横 3 通り × 縦 3 通りで 9 通りのサブピクセル位置を想定できます。
実際に 9 枚すべてを用意するかは絵柄次第ですが、「どの中間位置を何枚持つか」を設計しやすくなります。
GameDev StackExchangeでよく語られる 9 通り案は、この整理に向いています。
私は差分絵を作るとき、輪郭をそのまま 1px ずらすのではなく、重心が移ったように見える内部差分を優先します。
足の前側の影を 1px 足す、髪の前縁の明部を片側へ寄せる、マントの折り返しだけを進行方向へ押す、といった作り方です。
これなら整数スナップの硬さを保ったまま、中間速度の情報だけ足せます。
公開されている公式ドキュメントや検索結果では、Aseprite に明示的な「サブピクセル専用グリッド」機能が記載されているページは確認できません（Aseprite の標準ワークフローとしては、2x や 3x の高解像度で差分を描いてから縮小・運用する方法がコミュニティでよく使われます）。

補間・スーパーサンプリングの長所短所

ここまでの方法は「表示は整数ピクセル」が前提ですが、別の方向として バイリニア補間 や スーパーサンプリング もあります。
バイリニア補間は周囲 4 ピクセルを混ぜて中間色を作る方式で、小数位置に置いたスプライトでも滑らかに見えます。
スーパーサンプリングは高解像度で描いてから縮小する方法で、空間的なギザギザを抑える力があります。

長所は明快で、微速移動でもコマ落ち感が減り、カメラパンや背景スクロールが柔らかくなります。
UI や高解像度の背景、ピクセル感を前面に出さない演出画面では、この滑らかさがそのまま利点になります。

一方で、ピクセルアートのキャラにそのまま使うと、輪郭のエッジが混色でにじみます。
Point なら角として見えていた場所が、Bilinear では 2 色や 4 色の平均になり、ドットの一粒ごとの存在感が薄れます。
サブピクセルレンダリングの話で出てくる「見た目の解像感を稼ぐ」方向とは似ていますが、ゲームのスプライトでは、文字のシャープさとは逆に輪郭の意図が崩れる場面が多いです。

スーパーサンプリングも同じで、高解像度から縮小すれば滑らかさは得られますが、その縮小結果が必ずしもドット絵らしい絵になるわけではありません。
2x なら描画ピクセル数は 4 倍になるので、見た目のために払う負荷も増えます。
UI や背景の一部には向いていても、プレイヤースプライトを常時その経路に通すと、狙っていたピクセル感が後退します。

そのため、私は役割を分けています。
キャラ、敵、タイルは Point ベースで整数スナップ、UI や一部の遠景は Bilinear や高解像度縮小も許容、という分離です。
同じ画面の中でも、全部を同じフィルタで処理しないほうが破綻が少なくなります。

ピクセルパーフェクト設定チェック

実装が合っているのに絵だけ落ち着かないときは、たいてい設定の基準がどこかで食い違っています。
確認したい項目は多くありませんが、ひとつでもズレると揺れやぼやけが出ます。

• テクスチャフィルタが Point または Nearest になっているか確認する
• ピクセルスナップが有効になっているか

Unityなら Texture Importer の Filter Mode を Point (no filter) にし、2D Pixel Perfect の Pixel Snapping を有効化し、Reference Resolution と Assets PPU を揃える構成が軸です。
タイルだけ別 PPU、キャラだけ別スケール、カメラだけ小数追従、といった食い違いが入ると、個々の設定は正しく見えても画面全体では噛み合いません。

0.5px/フレームのキャラをきれいに見せたい場面でも、答えはひとつではありません。
論理座標は 0.5 ずつ進め、表示は隔フレームで 1px 動かし、その間だけ“0.5px 見え”の差分絵を挟む。
この組み合わせが、ピクセル感と移動の滑らかさを最も両立させやすい形です。
輪郭を守るのか、動きの連続性を優先するのかをパーツごとに切り分けると、実装と作画の役割分担も明確になります。

よくある失敗パターンと対策

色にじみ

いちばん誤解されやすいのが、テキストを画像に焼き込んだ瞬間に起きる色にじみです。
液晶の 1px は RGB の副画素で構成されているので、サブピクセルレンダリング済みの文字は横方向の見かけ解像度を稼げます。
しかしその前提は、描画先の配列と向きが合っていることです。
ここで一度 PNG に焼いてしまうと、もともと見えない前提だった赤や青の縁が、別の表示条件でそのまま露出します。
UI ラベルをキャプチャして素材化したときに、こちらのモニターでは締まって見えていた文字が、別の画面では赤青のフリンジを帯びて見えるのはこのパターンです。

文字素材を画像として持つなら、最初から グレイスケール AA か、ヒンティング済みの単色 に寄せたほうが安全です。
サブピクセル前提の処理は、画像編集時に固定するより、表示時のレンダラ側へ任せたほうが破綻が出ません。
とくにUnityの UI や OS 標準のテキスト描画を使える場面では、文字だけはテキストのまま保持し、画像化しない構成のほうが後工程で困りません。

この問題は比較図があると一目で伝わります。
同じ文言を「サブピクセル AA 焼き込み PNG」と「グレイスケール AA」の 2 列で並べると、回転や縮小をかけた瞬間に差が出ます。
前者は輪郭の左右に色が残り、後者は少し柔らかくなっても色縁が出ません。
実制作では、この差がそのまま量産時の事故率になります。

ぼやけ

ぼやけは、絵の描き方よりも表示経路で起きることが多いです。
原因はほぼ決まっていて、非整数スケール、線形補間、小数座標のまま描画 のどれかです。
たとえばドット絵のスプライトを 2 倍や 3 倍ではなく中途半端な倍率で拡大すると、元の 1px が画面上の複数ピクセルに均等に割り切れず、輪郭が混色されます。
さらにフィルタが Bilinear になっていると、周囲 4 ピクセルの平均色で補間されるので、角だった輪郭が溶けたように見えます。

私は縮小プレビューを見ながら調整するとき、この差を何度も踏みました。
線形補間が入った状態では、細い輪郭や 1px のハイライトが濡れたように広がって見えます。
そこから Nearest に切り替えた瞬間、輪郭の境界が立ち直って、どのドットを読ませたいのかが一気に揃います。
この記事でもその場面はスクリーンショットで見せる予定で、設定を変えただけなのに印象が別物になることが伝わるはずです。

対策は単純で、表示倍率を整数にそろえ、テクスチャフィルタを Point または Nearest に固定し、描画直前に座標を round か floor でピクセル格子へ合わせます。
Unityなら Texture Importer の Point (no filter) と、2D Pixel Perfect の基準解像度・スナップ設定を揃えると、原因の切り分けが一気に進みます。
絵そのものを修正する前に、まずサンプラと座標を疑うべき場面です。

ジャダー

ジャダーは、ぼやけとは逆に「シャープなのに動きが落ち着かない」症状です。
代表例は、ロジック上は滑らかに動いているのに、表示では 1px 飛ばしや足踏みのような揺れが見えるケースです。
カメラ速度とフレーム更新の刻みが合っていないと、あるフレームでは 0px、次のフレームでは 1px という配分になり、等速移動のはずなのに見た目だけ不均一になります。

ここで効くのが、ロジックを固定 Δt で進め、描画時だけピクセル格子へ丸める整理です。
さらに、カメラも被写体と同じ規則で整数スナップさせないと、スプライトだけがきれいでも背景が別テンポで揺れます。
Unityで Assets PPU を 16 にした構成なら、1px 分は 0.0625 ワールドユニットです。
キャラの移動量やカメラ追従の刻みをこの整数倍に合わせると、1 ピクセル単位の動きとワールド座標の関係が揃います。
ここがずれると、絵は正しいのに視線だけが引っかかります。

ジャダー対策で見落とされやすいのは、丸め処理の場所が複数ある状態です。
物体側で round、カメラ側で floor、UI 側はそのまま小数、というように規則が分かれると、どれも単体では正しそうに見えて、合成結果だけが揺れます。
動きを滑らかにしたくて速度を小数にしたなら、表示系のスナップ規則まで一緒に設計しておく必要があります。

配列不一致・回転

サブピクセルを焼き込んだ画像が危ない理由は、画素配列が固定ではないからです。
RGB を前提に作った縁取りは、BGR 配列では色の並びが逆転しますし、画像が 90 度回転した時点で横方向に最適化した情報が縦方向へ倒れます。
OLED を含む特殊配列では、そもそも期待した色分離になりません。
文字のシャープさを稼ぐ技法は、表示側がその配列を知っていて初めて成立します。
素材として配布した時点で、その前提が失われます。

この種の不一致は、作っている最中ほど気づきにくい設計です。
自分のメインモニターで見ているぶんには整って見えるので、PNG 化した時点で安心してしまいます。
ところが UI を回転させた瞬間、あるいは別の筐体へ持っていった瞬間に、赤と青の片寄りだけが目立ちます。
サブピクセルレンダリングは表示技術としては有効でも、汎用画像素材の作法として持ち込むと一気に不安定になります。

対策は明快で、サブピクセル前提の画像を作らない、配布しない ことです。
テキストは OS やライブラリの描画に任せ、画像として保存するならグレイスケール AA か単色で止めます。
とくに回転・拡縮・色変換を通る UI パーツは、この原則を守るだけで事故が減ります。

キャプチャ再利用の落とし穴

作業の流れとして起きやすいのが、ある端末で表示した文字や UI をキャプチャし、その画像を別の画面でも再利用するパターンです。
制作途中では手早く見えても、ここで固定されるのは「文字」ではなく、その端末上で一度レンダリングされた結果です。
つまり、端末 A で最適だった副画素の配列や補間結果まで一緒に持ち出してしまいます。
端末 B で色ズレして見えるのは不具合というより、最初から別物を貼っている状態に近いです。

私はこの手の差を、ゲーム内のラベル、設定画面のタブ、チュートリアル用の注釈画像で何度も見ました。
キャプチャした時点ではくっきりしていた文字が、別解像度へ載せた途端に縁が滲み、縮小時には細部が崩れます。
見た目だけを借りるつもりでも、再利用しているのはレンダリング条件ごと固まった画像です。
だから、後からスケールや配置を変えるほど問題が表面化します。

この落とし穴を避けるには、文字や図形を ベクタかテキストのまま保持し、表示先で再レンダリングする ことです。
スクリーンショットを説明図として使う場面でも、テキスト部分まで素材化しないほうが後で強いです。
比較用の図版を作るなら、同一テキストを「サブピクセル AA 焼き込み PNG」と「グレイスケール AA」で並べ、縮小・回転・別背景に載せた差を見せる構成が向いています。
実制作で避けるべきものが、そのまま視覚的に伝わります。

どの場面でどの手法を選ぶべきか

UI文字

UI の文字で迷ったら、選択肢はほぼ決まります。
文字は画像として焼き込まず、OS や描画ライブラリのテキストレンダリングに任せるのが基本です。
1px は通常 RGB の 3 つの副画素で構成され、横方向にはその単位を使って解像感を稼げるので、文字のような細い縦線ではサブピクセルレンダリングが効きます。
液晶向けの文字描画が長く支持されてきた理由もここにあります。

ただし、この利点は「表示時に副画素配列を理解した側が描く」から成立します。
画像に焼いた文字をあとで拡大縮小したり、回転させたり、別の表示系へ持っていったりすると、文字そのものではなく副画素の色配置まで固定されてしまい、縁の赤青が目立ちます。
UI ラベル、数値、アイコン横の注記のように再配置やスケール変更が入りやすい要素ほど、この差が出ます。
私は設定画面の小さな説明文だけ PNG 化した案件で、見た目を先に固めた結果、後から解像度違いのレイアウトに載せ替えたときに文字だけ浮いたことがありました。
テキストを最後までテキストのまま持っていた画面は崩れず、画像化した画面だけ手直しになりました。

UI では、サブピクセルレンダリングは表示技術として使うものであって、素材に埋め込むものではないと考えると判断がぶれません。
ベクタやフォント描画で保持し、最終表示時にレンダラへ解決させる。
これが拡大縮小や回転への耐性をいちばん確保できます。

ゲームスプライト

ゲーム中のスプライトは、文字とは別の考え方が要ります。
基本はロジックを小数座標で持ち、描画時だけピクセル格子にスナップするやり方です。
物理や追従計算は float のまま進め、見た目だけ整数へ寄せると、操作感と画面の安定を両立しやすくなります。
Unityなら2D Pixel Perfectの Pixel Snapping や基準解像度の設定がこの整理に向いています。

ピクセル感を優先する前景スプライトでは、テクスチャフィルタはFilterMode.Pointが軸です。
最近傍サンプリングはエッジをそのまま保てるので、キャラクタや弾、UI と隣接する重要物に向いています。
その代わり、非整数スケールではピクセルの拾われ方が不均一になりやすいので、整数スケール前提の構成と相性が良いです。

1px 未満の視覚差が欲しい場面では、差分スプライトを併用すると効きます。
0.5px 相当の見た目が欲しいなら 2 倍解像度で差分を作って縮小表示する方法が堅実ですし、さらに細かく詰めるなら 1/3px 相当の差分を用意する考え方もあります。
表示解像度を 3 倍基準で持つ発想では、位置差分の組み合わせが増えるぶん管理コストも上がるので、常用するより「特定の歩行」「ホバー」「わずかな重心移動」だけに絞るほうが制作は回ります。

私がよく使う判断は単純で、ゲームプレイ上の読みやすさを優先する対象は「小数座標＋描画スナップ」、見た目の粘りを足したい対象だけ「差分スプライト追加」です。
全部を差分化すると管理が膨らみ、全部を補間に任せるとドットの芯が失われます。

比較の要点を用途別に切ると、だいたい次の整理に落ち着きます。

• サブピクセルレンダリング: 文字向け。細線の視認性を稼げる反面、画像焼き込みには向きません。
• サブピクセルアニメーション: 呼吸や重心移動向け。輪郭を保ったまま微妙な動きを足せますが、色数が少なすぎると設計が難しくなります。
• 小数座標＋スナップ: プレイヤーや敵、当たり判定のある移動体向け。ロジックは滑らかで、表示はピクセル格子に合わせられます。
• 補間（バイリニア）: 背景や遠景向け。滑らかな流れを作れますが、前景のドットには向きません。
• 差分スプライト: 主役の見栄え調整向け。狙った方向にだけ密度を足せる代わりに、枚数管理が増えます。

カメラ移動

カメラは、スプライト以上に整数スナップの恩恵が大きいです。
被写体だけきれいでも、カメラが小数で流れると画面全体が揺れて見えます。
横スクロールや見下ろしで「なんとなく酔う」画面は、スプライトではなくカメラ側の規則がずれていることが多いです。

ピクセルアートの主画面では、カメラを整数ピクセルにスナップし、表示スケールも整数倍にそろえるのが軸になります。
これで前景スプライト、タイル、当たり判定の見た目が同じリズムで揃います。
Unityの Pixel Perfect Camera はそのための部品として素直で、Assets PPU を 16 にした構成なら 1px が 0.0625 ワールドユニットに対応します。
キャラの移動もカメラ追従もこの刻みに沿わせると、1 ピクセル単位の動きが崩れません。

ただ、全レイヤーを同じ扱いにする必要はありません。
STG の背景を流すときは、遠景だけバイリニア補間で滑らかに動かし、前景スプライトは Nearest のまま固定する構成がよく効きます。
私も横スクロール STG の画面設計では、背景の星雲や遠い構造物は線形補間で流し、プレイヤー機・敵・弾・HUD は Point のままに切り分ける案をよく図に起こします。
この混在は相性が悪そうに見えて、役割分担が明確ならむしろ見やすいのが利点です。
背景には連続感が出て、前景にはドットの輪郭が残ります。
設定の実例としては、背景レイヤーだけ別レンダーテクスチャに分けてバイリニア、ゲームプレイに直結する前景は整数スナップ＋最近傍、という組み方が収まりやすいのが利点です。

カメラで避けたいのは、中途半端な折衷です。
全体を小数で流しつつ一部だけ丸めると、レイヤーごとに違うテンポで揺れます。
滑らかさをどこに使い、ピクセル固定をどこで守るかを最初に決めておくと、画面全体の説得力が揃います。

呼吸・軽微アニメ

呼吸や待機モーションのような軽いアニメでは、輪郭そのものを毎回ずらすより、輪郭を固定して内部の明暗やハイライトだけを動かすほうがまとまります。
2〜4 フレームでも十分で、胸元の陰、頬の明るさ、髪のハイライト、服のしわの一部だけをずらすと、体が少し前後しているように見えます。

この方法が強いのは、ドットの外形を守れるからです。
小さなスプライトで輪郭まで頻繁に動かすと、1px の差がそのまま体格変化に見えてしまいます。
ところが内部色だけを入れ替えると、シルエットは止まったまま、空気だけが動きます。
少色パレットでも効果が出やすいのはここです。
明度差をひとつ持っているだけで、呼吸の深さや重心の移動を感じさせられます。

実制作では、待機モーションを「体を動かすアニメ」として考えすぎないほうが収まりが良いです。
私はまず輪郭固定の 2 フレームを作り、そこで物足りなければ 3 フレーム目にハイライトだけ足します。
肩線や頭頂を毎回触るより、胸の陰影や目元の明るさだけをずらしたほうが、止め絵として見たときの完成度も落ちません。
軽微アニメは枚数の多さより、どこを固定し、どこだけ揺らすかの設計で差が出ます。

高DPI環境の補足

現代の高 DPI 環境では、文字のサブピクセル AA の効き方は昔ほど単純ではありません。
画素密度が上がるほど、横方向の副画素を使って稼ぐ解像感の恩恵は視認上で縮みます。
文字が十分細かく表示できるなら、グレイスケール AA でも荒れが目立ちません。
テキストでサブピクセルレンダリングが不要になる場面があるのはそのためです。

一方、ピクセルアート側では話が逆です。
整数スケール前提で表示し、前景を Point で保つなら、そもそも副画素単位の補助を必要としない場面が多いです。
見せたいのは液晶上の「細線の見え方」ではなく、元絵のピクセル構造そのものだからです。
高 DPI になっても、整数倍で表示されたドットは依然として意味があります。
むしろ中途半端な非整数スケールや補間のほうが、ドット絵らしさを崩します。

つまり、高 DPI 環境では「文字はサブピクセルに頼らなくても十分読めることがある」「ピクセルアートは整数スケールなら副画素の助けがいらない」という二方向の整理になります。
どちらも精細だから同じ扱いで良い、とはなりません。
文字は可読性、スプライトは形状保持という別の目的で見たほうが、手法の選択を誤りません。

練習課題：16x16または32x32で試すサブピクセル表現

課題1: 16x16球体の0.5pxシフト

最初の練習は、いちばん小さい条件で「半ドット動いたように見える差」を体に入れることです。
16x16の球体か顔アイコンを1つ用意し、2フレームだけ作ってください。
ここで触るのは輪郭線ではなく、右方向への重心を感じさせる内部差分だけです。
輪郭が1pxでも跳ねると、動きではなく形の崩れとして見えてしまいます。

1枚目をBefore、2枚目をAfterとして並べます。
Afterでは、右端列の上側と下側でいちばん角に近い中間色を1pxだけ置き換え、さらに内部の暗色を1pxだけ右へ寄せます。
たとえば球体なら、右端列の最上・最下の丸みを支えている中間色を少し明るくするか、隣接色に差し替えるだけで、輪郭はそのままなのに光が右へ回ったように見えます。
顔アイコンなら、頬の影や口元の下の暗部を1pxだけ横移動させると、頭全体が右へ寄った印象が出ます。

この課題では、差分の場所を自分で言語化しておくと伸びが早いです。
私は作業するとき、どのピクセルを替えたのか後で見返せるよう、注釈付きの小さな図を必ず作るつもりで進めます。
円の右端列の最上段寄りと最下段寄り、内部の影の中心、ハイライトの受け側といった具合に、変更点を明記しておくと、偶然うまくいったのか、狙って効かせられたのかがはっきりします。

A/B比較では、2枚を交互再生するだけでなく、横並びでも確認してください。
交互再生で動いて見えても、静止比較で輪郭が暴れていたら失敗です。
狙いは「右へ0.5px動いた」ではなく、「右へ重心がわずかに移った」と読ませることにあります。

課題2: 32x32呼吸アニメ

次は32x32で、呼吸のふくらみとしぼみを3〜4フレームで作ります。
ここでも外形線は固定です。
肩線、頭の外周、胴体のシルエットはそのままにして、ハイライト、影、AAだけを1px単位で動かします。
輪郭まで一緒に動かすと、呼吸ではなく拡大縮小のアニメに見えやすくなります。

たとえば正面向きのキャラなら、胸の中央寄りにある明部を1px上か外側へ寄せ、脇腹の影を少しだけ下げると、息を吸った瞬間の張りが出ます。
吐く側のフレームでは逆に、明部を少し戻し、影の面積を増やします。
AAも見逃せません。
輪郭に接している中間色を1pxだけ入れ替えると、外形を動かさずに表面の丸みだけ変えられます。
私が待機モーションを詰めるときは、まず本体色よりAAの置き場所から見直すことが多いです。
小さな差なのに、胸郭の柔らかさや頬の前後感がそこで決まるからです。

フレーム構成は、通常、吸う、最大、吐く、戻るの4段にすると観察しやすくなります。
3フレームにするなら、中央フレームを共用して往復させるだけでも十分です。
Before/After比較も残してください。
静止1枚目と、いちばんふくらんだフレームを並べると、何を動かしたのか自分でも把握しやすくなります。

ここでも注釈図の準備が役立ちます。
胸のハイライトをどこからどこへ移したか、脇の影をどの列で増減したか、頬のAAをどの段で差し替えたかを印で示しておくと、修正の指針がぶれません。
呼吸アニメは枚数より、どの差分が「空気の出入り」に見えるかの設計で決まります。

課題3: カメラ/スプライト実装テスト

作画で作った差分を、ゲーム画面で破綻なく見せられるかまで確認すると理解が一段深くなります。
ロジック上の座標はfloatで持ち、描画時だけroundかfloorでスナップする構成にしてください。
見た目を整数ピクセルへ着地させつつ、内部では連続した移動量を持てるので、当たり判定や速度計算を崩さずに済みます。

スプライト側では、通常絵に加えて「0.5px相当」の差分スプライトを用意します。
速度が遅い区間では通常絵、移動の途中では差分絵、と交互に描画するだけでも、見た目の滑らかさが増します。
3x表示解像度で全方向差分を抱える設計も考えられますが、練習ではまず横移動だけで十分です。
右移動中に通常・差分・通常・差分と切り替え、左移動では逆向きの差分を使うと、サブピクセル表現が実装上どう効くかを観察できます。

Unityで試すなら、前述のPixel Perfect Cameraを使った構成が整理しやすいのが利点です。
Assets PPUを16にそろえているなら、1pxは0.0625ワールドユニットとして扱えます。
キャラ移動やカメラ追従をこの刻みの倍数で運ぶと、ロジックと見た目の対応が崩れません。
描画はPoint、カメラは整数スナップ、表示スケールも整数倍にそろえると、差分スプライトの検証結果が読み取りやすくなります。

floorとroundの違いも見比べてください。
floorは常に片側へ寄るので、低速移動で引っかかるようなリズムが出ることがあります。
roundは中央付近で前後の揺れが減る場面が多く、キャラの見た目には素直です。
実際の画面で比較すると、紙の上では同じに見えた差分でも、カメラが絡んだ途端にふるえが見えてきます。
ここで初めて、作画の差分と実装の丸め規則が一体であることが腹落ちします。

チェックリスト

仕上がりの確認は、次の4点に絞ると判断が速くなります。

• 線のふるえがなく、輪郭の位置がフレームごとに跳ねていない
• 目的方向への重心移動が感じられ、ただの明滅になっていない
• ぼやけや色にじみが出ておらず、ドットの境界が保たれている
• Before/Afterを見比べたとき、どの1px差分が効いているか説明できる

関連記事: 差分スプライトの作り方 ・ Unity Pixel Perfect 実装ガイド

（注）現在サイト内に該当する記事がない場合は、上記スラッグを将来の記事スラッグとして活用してください。