調色板繪圖技術在 J2ME 遊戲中的工程實踐：原理、數據結構與性能權衡

位圖 vs 調色板：核心取捨

調色板核心數據結構

// 螢幕幀緩衝（RGB32）
class RGBImage {
    int width, height;
    int[] pixels; // length = w*h
}

// 調色板圖集（128 色，索引用 signed byte）
class PaletteImages {
    int[] palette = new int[128];       // ARGB 調色表
    int imageCount;
    int[] imageSize;        // [w0,h0, w1,h1...]
    int[] imageOffset;      // 每圖在 data 起始索引
    byte[] indices;         // 連續索引流：圖0所有像素, 圖1所有像素...
}

為何 128 色？ Java byte 範圍 -128~127，避免無符號轉換開銷；實戰證明 128 色足夠表現力。

JAR 壓縮無憂慮：PNG 與 JAR 同用 LZ77，原始索引流入 JAR 後體積相當。

渲染管線：單次 drawRGB 提交

1. 邏輯層將可見實體（背景層、角色、特效）按深度合成到 RGBImage 像素陣列
2. 合成過程中直接處理 Alpha 混合、換色、翻轉（8 向查表/運算）
3. 幀末一次 Graphics.drawRGB(rgbData, 0, width, 0, 0, width, height, true) 上屏

實測 Nokia 7610：8 層背景 + 10 角色，無額外優化，**100-120ms/幀** 可接受。

幀率優化：拋棄 Thread.sleep，改用忙等待時間片

// 典型 sleep 寫法 ~10 fps (Symbian 7.0)
Thread.sleep(frameDelay);

// 高精度忙等待 ~13 fps
long next = System.currentTimeMillis();
while (running) {
    long now = System.currentTimeMillis();
    if (now >= next) {
        gameUpdateAndRender();
        long cost = System.currentTimeMillis() - now;
        next = (cost >= frameDelay) ? now + cost + 1 : now + frameDelay;
    }
}

原理：利用 JVM 內部高精度時鐘避免 Thread.sleep 最小調度粒度損耗。

C/C++ 移植對照結構

typedef unsigned char  U8;
typedef unsigned short U16;
typedef unsigned long  U32;

struct Size { int w, h; };

struct RGBImage { Size sz; U32* pixels; };           // 32-bit framebuffer
struct PaletteImages {
    U32* palette;           // 256 色無符號問題
    int   imageCount;
    Size* sizes;
    int*  offsets;
    U8*   indices;          // 8-bit 索引
};

C 端自然支援 256 色調色板，索引用 U8 無符號運算更簡潔。

工程建議

• 若目標機型 CPU 弱（早期 40MHz ARM），優先用系統 drawImage。
• 6600/7610 等 60 系列調色板與系統 API 速度持平，可全面採用。
• 自研內存管理（對象池、引用計數）可徹底杜絕 J2ME 堆錯誤。
• 非必要勿用執行緒，單線程忙等待更穩定高效。