一年多前也曾經嘗試但失敗

去到今天終於成功在xcode上面把圖片畫出來了！

簡單的把原理寫出來

1. 讀取real.bin中的bytes array
2. 從指定的地址當中抽取pixels
3. 若果要存成bitmap方便瀏覽的話，要先自己製作bitmap header 及DIB header , 並把palette填上
4. 若要在cococ2dx中畫成sprite
   1. 先把pixels變成palette的顏色 (這邊我選了RGB8888 , 保留了alpha channel)
   2. 把填了色的byte arrays變成一張texture
   3. 用ccsprite畫出來

當中最大的問題是

cocos2dx不支持RGB8 , 只有I8 及A8 ,　兩者好像都是用來做masking的

因此需要把RGB8的pixels 轉換成RGBA8888

直接讀取palette的顏色再寫進去就可以了

但畫出來的結果卻是上下倒轉

這點原因不明，可能是cocos2dx的bitmap處理方法不同?

折衷方法是我把上下填進去的次序調轉了

原來主要的原因是因為windows的bitmap格式

第一row是圖像的最底一行

So, in DIBs, the bottom row of the image is the first row of the file, and the top row of the image is the last row in the file. This is called a bottom-up organization. Because this organization is counterintuitive, you may ask why it’s done this way. Well, it all goes back to the OS/2 Presentation Manager. Someone at IBM decided that all coordinate systems in PM—including those for windows, graphics, and bitmaps—should be consistent. This provoked a debate: Most people, including programmers who have worked with full-screen text programming or windowing environments, think in terms of vertical coordinates that increase going down the screen. However, hardcore computer graphics programmers approach the video display from a perspective that originates in the mathematics of analytic geometry. This involves a rectangular (or Cartesian) coordinate system where increasing vertical coordinates go up in space.

In short, the mathematicians won. Everything in PM was saddled with a bottom-left origin, including window coordinates. And that’s how DIBs came to be this way.

來源: http://stackoverflow.com/questions/8346115/why-are-bmps-stored-upside-down

再來下一步就是讀取adrn_1.bin了…