110,571
社区成员
发帖
与我相关
我的任务
分享传奇3的wix,wil和map文件如何用C#打开？100分求解
如题？
我想了解一下游戏文件打包问题，
我现在已经知道的：
1.wix和wil好像都是二进制文件，
2.有文件头，貌似是C++的头，
3.wix文件时wil文件的索引，
4，wil文件中的除了文件头外的主要数据应该是二进制的图片，
问题：用C#
如何读取wix文件的内容，
如何读取wil文件的图片以及文件头的信息，并把图片显示出来，
如何通过map文件把地图文件显示出来？
想要知道读取时编码转化等，我用二进制读的时候不同的编码会有不同的结果，很郁闷，感觉很乱，对于如何入手真是一无所知，故来讨教高手，还望指点指点，要用到怎样的方法和类库
有代码最好只要C#的，事实上我觉得这也有利于学习C#读取C++二进制文件
原因，想直接调用传奇3的文件用来做我的游戏资源文件，感觉它用到的压缩文件的方案也很不错（我用别人编写的编辑器导出过图片然后自己用zip或rar在压缩，可不管怎么压缩都不如原来的文件小），我在网上找了很久但一直都没有头绪，
我有传奇3，ei2.0的C++的源码，但是因为缺少DirectX老的SDK文件所以调试没通过。而且本人对C++很感冒，一窍不通。
还是C#吧，期待高手出现。。。
我想了解一下游戏文件打包问题，
我现在已经知道的：
1.wix和wil好像都是二进制文件，
2.有文件头，貌似是C++的头，
3.wix文件时wil文件的索引，
4，wil文件中的除了文件头外的主要数据应该是二进制的图片，
问题：用C#
如何读取wix文件的内容，
如何读取wil文件的图片以及文件头的信息，并把图片显示出来，
如何通过map文件把地图文件显示出来？
想要知道读取时编码转化等，我用二进制读的时候不同的编码会有不同的结果，很郁闷，感觉很乱，对于如何入手真是一无所知，故来讨教高手，还望指点指点，要用到怎样的方法和类库
有代码最好只要C#的，事实上我觉得这也有利于学习C#读取C++二进制文件
原因，想直接调用传奇3的文件用来做我的游戏资源文件，感觉它用到的压缩文件的方案也很不错（我用别人编写的编辑器导出过图片然后自己用zip或rar在压缩，可不管怎么压缩都不如原来的文件小），我在网上找了很久但一直都没有头绪，
我有传奇3，ei2.0的C++的源码，但是因为缺少DirectX老的SDK文件所以调试没通过。而且本人对C++很感冒，一窍不通。
还是C#吧，期待高手出现。。。
...全文
请发表友善的回复…
发表回复
mrsupersky 2010-10-28
- 打赏
- 举报
[Quote=引用 22 楼 hohai_wow 的回复:]
Wil文件的结构就已经非常之清楚了。比较遗憾的是，我最终还是没有成功把数据直接拷到BMP中，根据我的研究，发现这个数据量的大小根本不是80*70的16bit位图的大小，至少少了一半的数据。
数据少了一半是因为存在wil文件里位图是经过压缩过的，读取两个字节，如果碰到0xC0表示透明，然后再读取两个字节就代表透明的长度。如果继续碰到0xC1就是正常图像，长度在下两个字节。还有如果碰到0xc2,……
[/Quote]
要读取wil文件就必须先要解析Wix文件才可以的！
所有的图片信息都必须根据Wix文件得出
Wil文件的结构就已经非常之清楚了。比较遗憾的是，我最终还是没有成功把数据直接拷到BMP中，根据我的研究，发现这个数据量的大小根本不是80*70的16bit位图的大小，至少少了一半的数据。
数据少了一半是因为存在wil文件里位图是经过压缩过的，读取两个字节，如果碰到0xC0表示透明，然后再读取两个字节就代表透明的长度。如果继续碰到0xC1就是正常图像，长度在下两个字节。还有如果碰到0xc2,……
[/Quote]
要读取wil文件就必须先要解析Wix文件才可以的！
所有的图片信息都必须根据Wix文件得出
mrsupersky 2010-10-28
- 打赏
- 举报
[Quote=引用 21 楼 wanggangchun 的回复:]
底层的东西，我不懂，但想知道
[/Quote]
要读取wil文件就必须先要解析Wix文件才可以的！
所有的图片信息都必须根据Wix文件得出
底层的东西，我不懂，但想知道
[/Quote]
要读取wil文件就必须先要解析Wix文件才可以的！
所有的图片信息都必须根据Wix文件得出
mrsupersky 2010-10-28
- 打赏
- 举报
啊，我现在只能使用别人写的导出工具导出图片
hohai_wow 2010-10-18
- 打赏
- 举报
Wil文件的结构就已经非常之清楚了。比较遗憾的是，我最终还是没有成功把数据直接拷到BMP中，根据我的研究，发现这个数据量的大小根本不是80*70的16bit位图的大小，至少少了一半的数据。
数据少了一半是因为存在wil文件里位图是经过压缩过的，读取两个字节，如果碰到0xC0表示透明，然后再读取两个字节就代表透明的长度。如果继续碰到0xC1就是正常图像，长度在下两个字节。还有如果碰到0xc2,0xc3就是要和指定颜色进行混合的，我估计就是游戏里衣服颜色变化的方法。
按照这个应该就能解压缩图像。
数据少了一半是因为存在wil文件里位图是经过压缩过的，读取两个字节，如果碰到0xC0表示透明，然后再读取两个字节就代表透明的长度。如果继续碰到0xC1就是正常图像，长度在下两个字节。还有如果碰到0xc2,0xc3就是要和指定颜色进行混合的，我估计就是游戏里衣服颜色变化的方法。
按照这个应该就能解压缩图像。
wgc 2010-05-25
- 打赏
- 举报
底层的东西，我不懂，但想知道
mrsupersky 2010-05-20
- 打赏
- 举报
想过，试过，不过很挫！
qiqishardgel 2010-05-14
- 打赏
- 举报
关注中，帮顶！
特别安静 2010-05-14
- 打赏
- 举报
楼主自己做游戏？
tashiwoweiyi 2010-05-14
- 打赏
- 举报
接分来拉！
mrsupersky 2010-05-14
- 打赏
- 举报
看来是没戏了。。。在等他个两天就只能结了。。
zhuazhuqingchong 2010-05-14
- 打赏
- 举报
标记~
柳晛 2010-05-14
- 打赏
- 举报
[Quote=引用 2 楼 moonwrite 的回复:]
牛人啊
可以到广海 或 飘雪问问
广海论坛:外挂
飘雪论坛:破解
[/Quote]
看雪，不是飘雪...
牛人啊
可以到广海 或 飘雪问问
广海论坛:外挂
飘雪论坛:破解
[/Quote]
看雪，不是飘雪...
mrsupersky 2010-05-11
- 打赏
- 举报
...
mayonglong 2010-05-09
- 打赏
- 举报
帮顶~~
mrsupersky 2010-05-06
- 打赏
- 举报
[Quote=引用 8 楼 shigaofei1 的回复:]
传奇3的VC++源代码（很老的那种）
在我的下载里有我没改动过，我曾试过调试，可是要求太苛刻了，要DirectX8（7）的SDK，我没有，也不想装因为很烦，还要VC++6.0，太烦。。。
其实最重要的不是这个，而是因为我的磁盘空间有限250G硬盘实际只有223G，而我已经用去215G，实在不想再装任何软件了
[/Quote]
不好意思源代码上传了几次都上传不了，很郁闷，最近老是上传到2%的时候就没戏了。。。。
传奇3的VC++源代码（很老的那种）
在我的下载里有我没改动过，我曾试过调试，可是要求太苛刻了，要DirectX8（7）的SDK，我没有，也不想装因为很烦，还要VC++6.0，太烦。。。
其实最重要的不是这个，而是因为我的磁盘空间有限250G硬盘实际只有223G，而我已经用去215G，实在不想再装任何软件了
[/Quote]
不好意思源代码上传了几次都上传不了，很郁闷，最近老是上传到2%的时候就没戏了。。。。
mrsupersky 2010-05-06
- 打赏
- 举报
bbs.gameres.com的资料
http://bbs.gameres.com/showthread.asp?threadid=47752
http://bbs.gameres.com/showthread.asp?threadid=47752
水哥阿乐 2010-05-06
- 打赏
- 举报
游戏方面的水要多深有多深
mrsupersky 2010-05-06
- 打赏
- 举报
传奇3的VC++源代码（很老的那种）
在我的下载里有我没改动过，我曾试过调试，可是要求太苛刻了，要DirectX8（7）的SDK，我没有，也不想装因为很烦，还要VC++6.0，太烦。。。
其实最重要的不是这个，而是因为我的磁盘空间有限250G硬盘实际只有223G，而我已经用去215G，实在不想再装任何软件了
在我的下载里有我没改动过，我曾试过调试，可是要求太苛刻了，要DirectX8（7）的SDK，我没有，也不想装因为很烦，还要VC++6.0，太烦。。。
其实最重要的不是这个，而是因为我的磁盘空间有限250G硬盘实际只有223G，而我已经用去215G，实在不想再装任何软件了
mrsupersky 2010-05-06
- 打赏
- 举报
文件结构吗？
/*
新的mir3版的wil文件头，28字节
在文件开始处偏移24个字节的地方是本库文件里图像的数量。
*/
typedef struct tagNEWWILFILEHEADER
{
SHORT shComp; //用于压缩的数据 偏移 0
CHAR szTitle[20]; //描述性字串 偏移 2
SHORT shVer; //版本号 偏移 22
INT nImageCount; //图片数量 偏移 24
}NEWWILFILEHEADER, *LPNEWWILFILEHEADER;
/*
新的mir3版wil文件中的屏幕点的信息结构 17字节，增加了影子特性，多用了5个字节。
有多少个图像，就有多少个图像信息块
*/
typedef struct tagNEWWILFILEIMAGEINFO
{
SHORT shWidth; //图像宽度，以瓷砖数量表示
SHORT shHeight; //图像高度，以瓷砖数量表示
SHORT shPX; //每片瓷砖x方向的像素
SHORT shPY; //每片瓷砖y方向的像素
CHAR bShadow; //影子，这是新版增加的特性
SHORT shShadowPX; //影子x方向的像素，这是新版增加的特性
SHORT shShadowPY; //影子y方向的像素，这是新版增加的特性
DWORD dwImageLength; //图像的长度
}NEWWILIMAGEINFO, *LPNEWWILIMAGEINFO;
标注红色的地方不对，那两个值是图片对中心坐标的偏移量，作用玩过传奇的都知道，比如一把屠龙，坐标对位就应该将它放在人物的手里，这个信息就是拿来对位的。
仍然紧接上文，采用DMon-1.wil文件作为例子：
前28字节不分析了，Wil的文件头。紧接着的17字节是从0x1C位置处开始的，注意这个0x1C是根据对应DMon-1.wix索引文件来判断的。根据DMon-1.wix的第一个索引指向的位置就是0x1C，所以在此找到对应的第一张图片的相关信息。50 00，46 00是图像大小即80*70。后面的F0 FF,E1 FF实际上是负数-16，-31
33 07 00 D4 EF这5个字节没有仔细研究，估计和fsfool说得差不多吧。后面的DWORD是关键，94 0A 00 00，解释是dwImageLength; //图像的长度。这个破玩意儿害老子研究半天，直到今天仔细看了WHImage类才搞清楚，总算是所有的数据都对上了。请看dwImageLength的定义：
m_dwImageLength = m_wWidth*m_wHeight*sizeof(WORD);
可见dwImageLength就是图片的长*高的2倍。MD，我以前算总是对不上就是没有乘以2造成的。现在来算一下94 0A 00 00就是2708，再倍2得到5416，即0x1528，由于本图片首地址（包含图片头）偏移在0x1C，而实际数据在0x2C所以结束位置在2C+1528=1554。
再结合上一篇文章，在wix文件中的第一个图片偏移量是1C 00 00 00，接着的第二个是55 15 00 00，可见第二个图片在Wil文件中的偏移量是0x1555。而第一个文件的结束位置正好是0x1554，完全能对应上。
Wil文件的结构就已经非常之清楚了。比较遗憾的是，我最终还是没有成功把数据直接拷到BMP中，根据我的研究，发现这个数据量的大小根本不是80*70的16bit位图的大小，至少少了一半的数据。
首先是Wix文件的分析，泄露的源码载入的文件都是新格式，不是盛大经典热血传奇的文件格式。先看看Wix格式在程序中的定义：
typedef struct tagNEWWIXFILEIMAGEINFO
{
CHAR szTitle[20];
INT nIndexCount;
INT* pnPosition;
}NEWWIXIMAGEINFO, *LPNEWWIXIMAGEINFO;
很明显，前24bytes是20bytes的标题或者叫做字符串，紧接着是4bytes的图片总数，然后就是图片的偏移量了。用UltraEdit打开DMon-1.wix，观察数据，头数据和紧接着的一段数据如下所示：
前20字节全为00 ，然后的4字节是F4 10 00 00转换为10进制就是4340和对应的Wil文件内含的图片数目能对上（用Wil编辑器能验证）。后边开始的每4字节INT*就是图片的偏移量了。按照规律，总的Wix文件大小应该为20+4+4*4340=17384字节，和实际情况吻合。
这些是我搜到的别人研究的资料，大家看看，有什么办法吗？
/*
新的mir3版的wil文件头，28字节
在文件开始处偏移24个字节的地方是本库文件里图像的数量。
*/
typedef struct tagNEWWILFILEHEADER
{
SHORT shComp; //用于压缩的数据 偏移 0
CHAR szTitle[20]; //描述性字串 偏移 2
SHORT shVer; //版本号 偏移 22
INT nImageCount; //图片数量 偏移 24
}NEWWILFILEHEADER, *LPNEWWILFILEHEADER;
/*
新的mir3版wil文件中的屏幕点的信息结构 17字节，增加了影子特性，多用了5个字节。
有多少个图像，就有多少个图像信息块
*/
typedef struct tagNEWWILFILEIMAGEINFO
{
SHORT shWidth; //图像宽度，以瓷砖数量表示
SHORT shHeight; //图像高度，以瓷砖数量表示
SHORT shPX; //每片瓷砖x方向的像素
SHORT shPY; //每片瓷砖y方向的像素
CHAR bShadow; //影子，这是新版增加的特性
SHORT shShadowPX; //影子x方向的像素，这是新版增加的特性
SHORT shShadowPY; //影子y方向的像素，这是新版增加的特性
DWORD dwImageLength; //图像的长度
}NEWWILIMAGEINFO, *LPNEWWILIMAGEINFO;
标注红色的地方不对，那两个值是图片对中心坐标的偏移量，作用玩过传奇的都知道，比如一把屠龙，坐标对位就应该将它放在人物的手里，这个信息就是拿来对位的。
仍然紧接上文，采用DMon-1.wil文件作为例子：
前28字节不分析了，Wil的文件头。紧接着的17字节是从0x1C位置处开始的，注意这个0x1C是根据对应DMon-1.wix索引文件来判断的。根据DMon-1.wix的第一个索引指向的位置就是0x1C，所以在此找到对应的第一张图片的相关信息。50 00，46 00是图像大小即80*70。后面的F0 FF,E1 FF实际上是负数-16，-31
33 07 00 D4 EF这5个字节没有仔细研究，估计和fsfool说得差不多吧。后面的DWORD是关键，94 0A 00 00，解释是dwImageLength; //图像的长度。这个破玩意儿害老子研究半天，直到今天仔细看了WHImage类才搞清楚，总算是所有的数据都对上了。请看dwImageLength的定义：
m_dwImageLength = m_wWidth*m_wHeight*sizeof(WORD);
可见dwImageLength就是图片的长*高的2倍。MD，我以前算总是对不上就是没有乘以2造成的。现在来算一下94 0A 00 00就是2708，再倍2得到5416，即0x1528，由于本图片首地址（包含图片头）偏移在0x1C，而实际数据在0x2C所以结束位置在2C+1528=1554。
再结合上一篇文章，在wix文件中的第一个图片偏移量是1C 00 00 00，接着的第二个是55 15 00 00，可见第二个图片在Wil文件中的偏移量是0x1555。而第一个文件的结束位置正好是0x1554，完全能对应上。
Wil文件的结构就已经非常之清楚了。比较遗憾的是，我最终还是没有成功把数据直接拷到BMP中，根据我的研究，发现这个数据量的大小根本不是80*70的16bit位图的大小，至少少了一半的数据。
首先是Wix文件的分析，泄露的源码载入的文件都是新格式，不是盛大经典热血传奇的文件格式。先看看Wix格式在程序中的定义：
typedef struct tagNEWWIXFILEIMAGEINFO
{
CHAR szTitle[20];
INT nIndexCount;
INT* pnPosition;
}NEWWIXIMAGEINFO, *LPNEWWIXIMAGEINFO;
很明显，前24bytes是20bytes的标题或者叫做字符串，紧接着是4bytes的图片总数，然后就是图片的偏移量了。用UltraEdit打开DMon-1.wix，观察数据，头数据和紧接着的一段数据如下所示：
前20字节全为00 ，然后的4字节是F4 10 00 00转换为10进制就是4340和对应的Wil文件内含的图片数目能对上（用Wil编辑器能验证）。后边开始的每4字节INT*就是图片的偏移量了。按照规律，总的Wix文件大小应该为20+4+4*4340=17384字节，和实际情况吻合。
这些是我搜到的别人研究的资料，大家看看，有什么办法吗？
huanqun1020 2010-05-05
- 打赏
- 举报
关注中
加载更多回复（4）
