精靈圖還是 PNG 序列？2D 遊戲動畫匯出格式實測

精靈圖和 PNG 序列可以保留完全相同的透明動畫，但它們服務於不同階段。面向 2D 遊戲執行時，如果圖集尺寸符合目標硬體限制，而且匯入器能夠讀取影格區域，優先考慮精靈圖加後設資料。需要逐影格檢查、修改、替換、歸檔或繼續加工時，則應保留或匯出PNG 序列。

精靈圖並不會天然佔用更少記憶體，也不會在所有引擎裡都更快；PNG 序列也不等於執行時一定要載入 96 張獨立紋理。為了把區別說清楚，我們使用同一段公開 AnimGen 動畫進行實測：96 張 512 × 512 RGBA 影格，以 24 FPS 表現一段四秒的戰士揮砍動作。

不同環節需要的格式不同

實際專案裡最穩妥的方式往往不是二選一：用獨立影格作為可檢查的生產源，再為具體執行環境產生一張或多張精靈圖。

同一段動畫，兩種真實檔案包

本次使用的等軸視角戰士揮砍動作，也用於此前的透明格式對比。兩個檔案包中的 96 張畫布順序一致。精靈圖採用固定的 10 × 10 網格，其中 96 個格子存放影格，最後 4 個格子保持透明。配套 JSON 記錄 96 個 512 × 512 影格區域，並明確所有影格都沒有旋轉或裁邊。

可以直接檢查本文使用的全部檔案：

• 下載 5120 × 5120 精靈圖 PNG
• 檢視配套影格佈局 JSON
• 下載包含 96 影格的 PNG 序列 ZIP
• 檢視包含測量值和 SHA-256 的機器可讀記錄

我們先解碼了兩種表示，再進行逐影格比較。96 影格的 Alpha 數值全部完全一致；在來源圖 Alpha 大於 8 的可見像素中，RGB 也全部一致。完全透明像素中的 RGB 位元組不會影響合成結果，打包時還可能被歸一化，因此沒有把它們計入可見 RGB 對比。

這一步很重要：“同一段動畫”不應該只表示縮圖看起來相似。上述檢查確認，本次比較的變數是打包方式，而不是兩套視覺結果。

下載體積與檔案數量實測

這組範例得到的資料如下：

PNG 序列 ZIP 包含 96 張影格圖和一個 README。全部條目解壓後共 14,550,491 位元組；由於 PNG 本身已經壓縮，ZIP 對條目資料只額外減少約 0.9%。在這一個範例裡，精靈圖檔案包的下載體積比 ZIP 小 54.44%。

54.44% 不是通用的精靈圖壓縮比例。透明區域、重複像素、畫面細節、單影格尺寸、網格佈局、PNG 編碼器和 ZIP 設定都會改變結果。一張排列緊湊的精靈圖可能更好地壓縮重複的透明或相似區域，換一段動畫則可能得到不同結果。

還要注意：PNG 序列通過 ZIP 交付時，網路上下載的是一個檔案，而不是發起 97 次 HTTP 請求。“檔案很多”主要影響解壓、版本控制、編輯流程和執行時處理方式，不能直接等同於 97 個網路請求。

下載更小，不代表記憶體一定更少

PNG 檔案大小描述的是壓縮儲存或傳輸體積。渲染器通常需要先解碼像素，引擎還可能應用平臺紋理壓縮、mipmap、留邊或其他內部格式。

只按 RGBA8 做一個易於核對的基線：

• 5120 × 5120 精靈圖包含 26,214,400 個像素，每像素 4 位元組，正好是 100 MiB；
• 96 張 512 × 512 獨立影格共有 25,165,824 個像素，如果全部同時解碼並駐留記憶體，正好是 96 MiB；
• 精靈圖多出的 4 個未使用格佔 4 MiB，正好解釋兩者差值。

這不表示 PNG 序列執行時一定佔 96 MiB。工具可以每次只加載一影格、按需載入一部分、解碼後釋放，或者在構建階段重新打包；相反，引擎也可能把匯入的全部影格同時保留在記憶體。應該測量目標構建，而不是用下載體積推算視訊記憶體。

多個精靈引用同一張圖集時，確實更容易參與批處理，但“一張圖集”也不保證“一次 Draw Call”。材質、混合狀態、排序、Shader、渲染器規則和其他狀態切換仍會影響批次。

別忽略最大紋理尺寸

本文測量的精靈圖尺寸是 5120 × 5120。它當然可以作為 PNG 下載和檢視，但已經超過面向移動端與 WebGL 時常用的保守 4096 × 4096 基線。

Godot 目前的紋理尺寸說明建議，為了覆蓋更多平臺，應避免使用超過 4096 × 4096 的紋理，並指出移動 GPU 通常受這一尺寸限制。MDN 的 WebGL 最佳實踐也把 4096 視為廣泛可用的基線，同時提醒桌面裝置可能支援更大的紋理。

4096 是相容性基線，不是所有裝置的統一上限。Unity 可以通過 SystemInfo.maxTextureSize讀取目標硬體限制，WebGL 也可以查詢目前上下文：

const maxTextureSize = gl.getParameter(gl.MAX_TEXTURE_SIZE);

對本文這組 96 影格素材，如果保持每格 512 × 512，同時要求圖集不超過 4096，可以拆成：

• 一張 8 × 8、包含 64 影格的 4096 × 4096 圖集；
• 一張 8 × 4、包含 32 影格的 4096 × 2048 圖集。

拆分後，後設資料必須說明每一影格屬於哪張紋理。不要直接把 5120 像素的圖集縮小，卻繼續使用舊的 512 像素影格區域；那會改變單格尺寸並讓座標失效。其他可行方式還包括減小輸出影格尺寸、減少採樣影格數，或使用會針對目標環境佈局的引擎包。

後設資料到底解決了什麼

一張孤立的精靈圖並不知道應該如何播放。使用方至少需要影格區域和順序；具體專案還可能需要單影格時長、動作名、迴圈設定、源畫布、軸點、偏移和紋理檔名。

本文使用的公開 JSON 包含：

• 從 frame_0000.png 到 frame_0095.png 的鍵名；
• 每一影格的 x、y、w、h 區域；
• 源尺寸與 Sprite Source Size；
• 每影格 42 毫秒的整數時長；
• 覆蓋第 0–95 影格的 tactician_slash 標籤；
• 精靈圖尺寸與 RGBA8888 格式。

42 毫秒是 24 FPS 單影格時長的整數近似。如果專案需要嚴格的時間線同步，應讀取匯出 manifest 中的權威 FPS 或總時長，而不要假設經過取整的單影格整數在長動畫中仍然數學精確。

PNG 序列 ZIP 具有明確的檔名，README 記錄了 24 FPS、固定畫布對齊和建議的底部居中軸點；但 PNG 檔案本身不會儲存動畫順序、FPS、迴圈行為或遊戲狀態。序列影格必須和這些旁路資訊一起儲存。

所以，“精靈圖還是 PNG 序列”不僅是圖片格式選擇，也是後設資料選擇。

精靈圖和紋理圖集有關，但不完全相同

兩種說法經常混用，不過可以這樣理解：

• **精靈圖（Sprite Sheet）**通常按照規則橫條或網格擺放一段動畫的影格；
• **紋理圖集（Texture Atlas）**還可能混合不同素材、裁掉透明邊緣、旋轉區域，並用不規則矩形壓縮空間。

本次測試使用規則精靈圖。各影格既沒有裁邊，也沒有旋轉，因此始終保留同一個 512 × 512 畫布。它會浪費一部分透明像素，但影格間對齊和底部居中軸點也更直接。

更緊湊的圖集可以減少空白，不過匯入器必須正確處理源尺寸偏移、裁邊、旋轉、留邊和邊緣擴展。忽略這些欄位後，角色可能出現跳動、採到相鄰格或產生可見接縫。應當選擇目標匯入器能夠穩定還原的最緊湊結構；截圖裡的排列更緊湊，並不代表執行時也更可靠。

哪些情況更適合精靈圖

以下情況優先使用精靈圖加 JSON 或引擎包：

• 影格圖將進入即時 2D 執行環境；
• 圖集沒有超過目標平臺的實測紋理上限；
• 匯入器能夠讀取影格區域和時間資訊；
• 這段動作的影格通常會一起載入和使用；
• 共用紋理符合目前引擎的批處理與資產管理策略；
• 希望檔案包不容易被誤拆、漏影格或打亂順序。

如果目標是 Godot，可以繼續檢視單獨的 Godot 4 匯入實測。那篇文章驗證了針對執行時製作的小尺寸精靈圖、SpriteFrames、時間、軸點和實際播放。它使用每影格 96 × 96 的引擎包，因此沒有被混入本文 512 × 512 範例的體積表。

哪些情況更適合 PNG 序列

以下情況優先使用 PNG 序列：

• 美術需要修改或替換個別影格；
• 合成、編碼或自研工具需要按編號讀取圖片；
• 希望保留一份無損生產源，繼續派生 WebM、ProRes、精靈圖或引擎包；
• 整段動畫會超過安全紋理尺寸；
• 執行時可以只加載目前場景需要的影格或動作；
• 正在排查問題到底來自原始像素、打包、匯入、過濾還是播放。

當只有一影格變化時，獨立檔案也更容易在版本控制中比較。代價是檔名、時間、畫布和軸點必須始終與圖片保持同步，而且部分引擎匯入後仍會重新打包。

影片剪輯和網頁交付需要另一套選擇標準，可以檢視同一素材的 WebM Alpha、ProRes 4444 與 PNG 序列實測。

一套更穩妥的匯出流程

對遊戲專案來說，可以按下面的順序處理：

1. 打包之前先選擇並檢查真正可用的動畫區間。
2. 匯出獨立 PNG 影格，作為檢查或生產源。
3. 確認 Alpha、固定畫布對齊、影格順序、FPS 和軸點。
4. 根據目標平臺的最大紋理尺寸選擇輸出解析度。
5. 為目標環境打包一張精靈圖、多張精靈圖或專用引擎包。
6. 在小型測試場景中檢查時間、過濾、邊緣、軸點和迴圈端點。
7. 分開儲存影格序列、JSON、manifest 和已經驗證的執行時檔案包。

AnimGen 的精靈圖製作工具可以從產生動作或受支援的影片開始，選擇有效區間與影格數，再匯出 PNG 影格、帶 JSON 的精靈圖或引擎包。輸出格式說明列出了具體交付物；免費和付費格式權益則以目前定價與匯出權限為準。

人和工具需要獨立影格時，使用 PNG 序列。經過驗證的執行時能夠從共享紋理和可靠後設資料中獲益時，使用精靈圖。兩種格式分別服務於同一生產流程的不同階段時，就把兩種都保留下來。