石器時代檔案格式分析
希望廣大外掛程式製作者能參與到石器服務端的架設及其研究中來.
目前我們提供了服務端的源**和一些資料.架設環境是linux+orcle ? or linux + mysql
這個格式是從jssm提供的源**裡找到的.
作者的**:http://www.ghljj.com/sa.htm
adrn_9.bin 位址檔案
這個檔案有若干個大小一樣的塊組成，
每個塊長度80為位元組，格式如下：
魔力的graphicinfo.bin每個塊長度是40位元組。 char 未知[5];
其中偏移量xy是用於定位的，比如x=-18，y=-19，如果將顯示在(100,100)，那麼實際
位置應該是(82,81)，這樣才可以和其它協調，在做人物動作gif的時候必須用這個引數來調整
每一幀的位置，否則動作是抖動的。
real_9.bin 資料檔案
這個檔案包含了所有的原始資料，每個資料塊由資料頭+資料組成，
每個資料頭長度16位元組，格式為：
後三項和位址檔案中的一樣，塊長度包括了資料頭的大小。
在資料頭後面緊跟影象資料。
spradrn_1.bin 角色動作位址檔案
每個資料塊大小12位元組
spr_1.bin 角色動作資料檔案
該檔案存放了全部動作的序列，每個動作由資料頭+若干序列號組成，
資料頭長度12位元組。
有多少幀，後面就跟有多少個序列號，
每個序列號長10位元組，
號就是該幀所用的序號。
例如要解出340號角色的第20個動作，先在spradrn_1.bin中找到序號為340的資料塊，讀出位址和動作數，
然後根據位址在spr_1.bin中定位到對應的資料塊，現在的位置是在第0個動作上，一次讀到第20個去，
（每個動作的大小都由幀數決定）根據幀數讀出每一幀的號，通過號解出對應的就行了。
其中未知的字段表示我還不知道用處的。
根據這些解出的資料不是位圖格式，是用run-length演算法壓縮之後的資料，這類演算法很簡單，
我將幾個標誌位元組說明一下：
標誌一位元組 二位元組 三位元組 四位元組
0n string 長度為n的字串(n<=0xf)
1n m string 長度為n*0x100+m的字串
2x y z string 長度為x*0x10000+y*0x100+z的字串
8n x 填充n個x(n<=0xf)
9n x m 填充n*0x100+m個x
ax x y z 填充x*0x10000+y*0x100+z個x
cn 填充n個背景色(n<=0xf)
dn m 填充n*0x100+m個背景色
ex y z 填充x*0x10000+y*0x100+z個背景色
比如，c9表示填充9個背景色，d1 10表示填充0x110個背景色，12 50表示後面跟著乙個長度為0x250的字串，
91 02 30則表示將0x02重複0x130遍。
以上檔案格式在2.0也一樣，不過檔名有變化，作相應修改就行了
《石器時代》移動平台單機版製作中
process 2011 10.9 看了2天的 發現還是有必要debug服務端的 但是由於我想研究相對簡單的2.5版本，所以一直在搭2.5的linux服務端，最終雖然 編譯沒問題，但是客戶端始終是無法連線上服務端。暫且放棄2.5，有空再搭一下8.0版本。2011 10.6 又開始繼續了，2.5版本伺...
檔案格式分析
檔案格式實質上是資訊的一種的編碼方式，在windows中，採用副檔名來區分不同的檔案格式。文字格式 txt doc docx 音訊格式 txt arsii碼的方式存在 doc 以二進位制格式儲存 docx 作為乙個zip壓縮格式存在，是doc結合xml的一種格式，由於是分塊儲存，相比與doc檔案完整...
GPC檔案格式分析
作者按 罕徳岡曼先生重溫了 劍芒x曼史 這個遊戲，感慨萬千，老淚縱橫。想當年玩仙劍看到白布下的林月如也滅有哭過滴他，卻在本遊戲中香奈兒死的時候掉淚了 畢竟是前一天晚上才h過的亞 究竟本遊戲有滅有可以救香奈兒mm的方法呢？解出便知道了 gpc的壓縮比並不高，因為它使用遊程碼的關係。每個包的第乙個位元組...