- 閱讀權限
- 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
以上理論全只適合神獸傳奇, 魔弓傳奇及龍之沙漏，往後版本均有些少改動
＊如需轉載，請附加此帖連結 ＰＯＳＴ ＢＹ 黑－=HyperDream＊ |
-
總評分:
Good + 24
查看全部評分
|
發表於 09-3-1 09:59 PM
發表於 09-3-3 10:57 PM
支持你繼續整多d地圖, 分享俾我地
