- 閱讀權限
- 95
- 最後登錄
- 16-4-12
- 精華
- 3
- UID
- 1035628
- 帖子
- 1490
- 積分
- 4084
- 註冊時間
- 08-2-11
- 在線時間
- 1304 小時
- UID
- 1035628
- 帖子
- 1490
- 積分
- 4084
- Good
- 142
- 註冊時間
- 08-2-11
- 在線時間
- 1304 小時
|
魔力寶貝檔案結構分析 ── 圖像、地圖
若對編程沒興趣的可直接跳過
這些理論是有助製作魔力地圖
#1 本帖: 基礎理論
#2 下一帖: 續後版本的改動, 其他相關檔案訊息, 製作成果
#3 備用
約一年前本人開始構思自行製作一些魔力寶貝實景地圖,並進行實地取景。就是在遊戲中每隔一段距離便截圖,然後慢慢的逐張圖片合併起來。)這方法不僅費時傷神,取外景時亦受場景隨時間變化而限制截圖時間,所以當時只有集中於製作室內場景。之後亦因沒空閒亦沒有繼續製作。當時的作品1 當時的作品2
早前製作魔物分佈時打算再次製作實景地圖,剛巧找到這個網站中(梦见坡)的一篇文章CrossGate文件分析,並開始研究。所以以下對檔案的結構分析內容均來自這篇文章,有些亦是自行研究時的發現。
*若無法進入網頁請下載附件 fanicer.gif
簡介
若有截過圖或找Log檔的人都會會留意到整個魔力寶貝目錄有bin, data, Log, map, screenshot, Upl子目錄。Log及screenshot的作用顯然是儲存Log對話檔案及BMP格式截圖,data是儲存玩家登入的訊息。這篇文章集中介紹儲存bin目錄下的Graphic*_*.bin, GraphicInfo*_*.bin, palet_*.cgp以及map目錄下的*.dat檔案。這些檔案均需以二進制方式讀取,否則使用類似記筆本等軟件開啟只會看到一堆沒意義的空白和符號。
使用過See4CG的人大約了解魔力場景是由無數的小圖片組合而成,儲存這些圖片數據的便是Graphic*_*.bin檔案。由於此檔案只是儲存圖片的數據,這樣相等於桌面上的一大堆沒命名的文件,為這些圖片名命的索引檔案就是GraphicInfo*_*.bin。每次這些檔案有更新時,檔案名稱尾部的數字均會改變。
並非所有圖像數據都儲存在同一個檔案中,每個大版本均有其專屬的名稱,索引檔案與數據檔案的檔名是相應的。
圖片索引檔案(GraphicInfo*_*.bin)
那麼GraphicInfo*_*.bin這個索引檔案會儲存甚麼資訊呢?
它是由每塊長度為40字節(40bytes)的數據組成,這40字節結構如下
這些被索引編號的均包含所有圖像,如地面、建築物、物件、技能、人物、人物大頭照、寵物及遊戲界面,即是1.0及2.0的界面均能找到。編號在各版本的索引中都以0順序編號,地圖編號則不是,只有有關人物及寵物的動畫的畫格地圖編號才一概為0。在版本神獸傳奇+魔弓傳奇及龍之沙漏的地圖中,所有地面圖像均寬x高64像素x 47像素,偏移量X為 -32偏移量Y為 -24。
圖像檔案(Graphic*_*.bin)
為提取圖像,一般都會先讀取GraphicInfo*_*.bin索引檔案內容獲得圖像的地址,然後讀取相應版本的Graphic_*.bin圖片數據檔案。圖片數據檔案與索引檔案不同,它儲存了所有圖像的原始數據,而且沒有固定大小的數據塊,但每個數據塊均由兩部分組成︰標頭+數據。每個標頭均長16字節,結構如下︰
長度為16字節的標頭後面便是長度為(數據長度-16)字節的圖像原始數據,絕大部分均已壓縮的。簡單來說若要讀取龍之沙漏的第100張圖像數據,先在GraphicInfo Ex_*.bin找出第100項記錄,即起始位置為(40*100)字節,讀取地址address後便在GraphicEx_*.bin 中第address字節開始讀取16字節的標頭數據,確認圖像為已壓縮後便可以開始在第(address+16)字節讀取數據,並以以下解壓方式得出圖像。
解壓算法(Run-Length)
魔力寶貝圖像數據的壓縮方法為Run-Length算法,即將重複的數據以特定方法壓縮,
所以只需根據以下數項定義改變取讀數據的方式便可以。
首先由起始地址讀取第1字節稱為首字節(00)︰
請注意表格上的首字節中的數字及大楷字母均用作標示解壓方法,不需納入運算。
細楷a, bb, cc, xx均為十六進制的字符,運算前必需轉化成十進制,當中xx代表甚麼稍後解說。
先以神獸傳奇版本中第1個圖像「空」為例解說這個解壓運算。
讀取數據首9字節: d0 1f 02 41 41 d0 3c 86 41
首字節00: d0,根據上表需多讀1字節組成d0 1f 解成重複 0x01f次透明色,化成十進制為31點透明色,
然後到02字節為02, 即需讀取多2字節的數據為02 41 41, 0x41 即十進制65,解成 65 65
繼續讀取為: d0, 組合 d0 3c……60點透明色
續續便是07字節: 86, 組合成 86 41, 即6次0x41 => 65 65 65 65 65 65
「C9表示填充9個背景色,D1 10表示填充0x110個背景色,12 50表示後面跟著一個長度為0x250的字符串,91 02 30則表示將0x02重複0x130遍」
順序解讀出來的數據並不可以按順序由左上至右下繪圖,否則會輸出上下倒置的結果。
*對於這個解壓算法解釋可能有些含糊,若有不明白請留言或提出更好的解釋方法。*
調色板檔案palet_*.cgp
現在便解釋一下xx到底代表甚麼。魔力寶貝的每一幀圖像結構與gif相同,均是以一調色板控制色彩,一般來說gif的調色板有256種顏色,xx則代表調色板上第xx種顏色。這色板的來源就是bin目錄下的pal內的palet_*.cgp檔案,它亦是需以二進制方式開啟,結構為每3字節代表一種顏色,pal目錄內所有檔案大小均為708bytes(字節),即它儲存了236種顏色,但它第一種顏色是代表調色板的第16種顏色,所以檔案是代表第16-252種顏色。不過檔案由第241種顏色開始已沒有使用,其實際上只用了第16-240種顏色,前16及後16種顏色均是預設的。另外一提的是每3字節順序所代表的RGB值是BGR(剛好相反的),值亦是以十六進制代表,即網頁設計所使用的方式(FF, FF, FF 代表白色)。所以將xx化為十進制後,若xx>=16及xx<240,便可在palet_*.cgp檔案中以(xx-16)*3為起始位址讀取3字節獲得顏色,否則xx便代表以下顏色號。
基於這理論,魔力寶貝的場景變換其實是轉換了調色板而非大量的轉換圖像數據,而且最多只使用256種顏色。這可證明使用gif或png-8儲存魔力相片也不失任何一種色彩,不需要使用耗資源的bmp檔案。
常用的調色板有︰白天palet_00.cgp, 傍晚palet_01.cgp, 晚上palet_02.cgp, 凌晨palet_03.cgp及部分室內場景palet_12.cgp
地圖檔案 *.dat
花了極大的篇幅解釋圖像的顯示,終於來到地圖的部分,地圖的製成的先決條件是必須先到過該地方,因為所到之地的地圖數據會儲存在目錄map之下。依目前研究,目錄map\0為儲存固定地圖如芙蕾雅島、法蘭城等。目錄map\1則為儲存迷宮地圖如map\1\1為里歐波多的洞窟、城內的地下迷宮等。
地圖檔案*.dat整個檔案共分四大領域。
- 首20字節為檔頭,檔頭的頭3字節為固定字符MAP,隨後1字節為1,再隨後8字節均為0,
然後為分別2個DWORD(4字節)的數據,第1個表示地圖長度-東(W),第2個表示地圖長度-南(H)。 - 隨後W*H*2字節為地面數據,每2字節為1數據塊,表示地面的地圖編號,以製成基本地形。
- 再隨後W*H*2字節為地上物件/建築物數據,每2字節為1數據塊,表示該點上的物件/建築物地圖編號。
- 再隨後W*H*2字節為地圖標誌,每2字節為1數據塊,
數據塊第1字節為0或10,10表示該坐標能引發場景轉換,否則為0
數據塊第2字節為0、192或193,193表示不能穿越該坐標,反之為192,0表示沒地圖。
基於魔力寶貝的視角為45∘,(W*H*2)的數據中順序排列如下
因前期地圖大小全為64像素 x 47像素,偏移量x -32, y -24,所以可直接計算其x, y坐標。但相同算法應用在建築物上會移位,這必須自行根據情況而調控。本人製作情況︰若方塊6的w和h均設為1, 方塊7的分別設為2及1,方塊6的x坐標為 (w+h)*32,那麼在方塊6上的建築x坐標為(w+h)*32 + 偏移量x + 96
由於編號只由2字節組成,無法直接指向龍之沙漏的地圖,在製作地圖時地面編號 >=20000 則需加 200000,
建築物編號200-265 均不需顯示,25290及 >= 30000均需加上 200000
以上理論全只適合神獸傳奇, 魔弓傳奇及龍之沙漏,往後版本均有些少改動
*如需轉載,請附加此帖連結 POST BY 黑-=HyperDream* |
-
總評分:
Good + 24
查看全部評分
|