逍遥剑客

一直以来我都用TC而不用Windows的资源管理器的 今天在看MPQ文件格式, 在StormLib的网站上找到这么个东西: MPQ Plugin for Total Commander v 1.2.0.53 (1,87 MB) for Win95/98/NT/ME/2000/XP/VistaArchive plugin for Total Commander.

2012年6月7日19:31星际2的编辑器相对于魔兽3最大的改进就是数据编辑器了, 也正是这个改变, 让很多有兴趣自制地图的人放弃了这个想法. 为什么呢? 因为它太复杂了, 而且资料很少, 所以上手难度比较大. 但是一旦你学会了它, 你就会喜欢上这种编辑方式. 这个编辑器背后的实现原理, 也是非常值得程序员们去好好探索和借鉴的. 星际2中, 很多功能都是可以使用数据编辑器去"配置"出来的, 这就是

参考wowmapview写了一个小地图查看的控件, 可以载入*.wdl文件解析出一张类似于"卫星图"的东西WDL文件保存的是WOW地图的低精度高度数据, 冒似用来做远处的LOD的每个地图最大是64*64个tile, 而一个tile它保存了17*17 + 16*16个16位的高度数据. 如果生成一张512*512大小的小地图的话, 每个tile就只有8*8个像素因此, 我们只取17*

启动:WowModelViewApp::OnInit()         加载配置: WowModelViewApp::LoadSettings()         初始化主界面ModelViewer::ModelViewer()                   初始化图形, 载入MPQModelViewer::Init(), 得到文件列表加入树控件里         初始

Tutorial by Siretu让大多数接触星际2编辑器的人歇菜的原因, 就是这个数据编辑器(Data Editor). 不管你是个新手, 还是使用魔兽3的编辑器做过一些东西, 当你怀着满腔的热情准备做一张星际2的地图时, 数据编辑器就像挡在前面的一座大山, 让人恨不得撞死算了.这种情况同样发生在我身上. 我自信用魔兽3的对象编辑器用得炉火纯青了, 但是当我打开数据编辑器时, 连怎么做个Uni

个人对脚本语言认识不深, 尤其是动态语言...但是问了好多人为什么逻辑用脚本写, 答案都是不用编译这也只能怪DT的C++当初没设计好由于WOW的成功, 让lua几乎成了游戏脚本的标准原来的python/ruby/tcl啥的一下子就没落了, 都怪暴雪啊~虽然lua做为一个脚本语言来说, 非常的完美但是我对它不是很感冒, 可能习惯了C系语言的语法了对于C/C++/C#/Java/JS/AS类的我才看着

目前我了解到使用Mono做脚本的只有Unity和SecondLife, SpringEngine也有个扩展实现.当然, 最成熟的还是Unity于是下载了一个看看它的脚本是怎么应用的它的编辑器界面很简洁, 实际操作了一下才发现所有的功能其本上都是由inspector面板完成所有的GameObject都是由Component所组成, 如Mesh/Physics/Audio/Script等等脚本都是从M

编译冒似不编译没有.lib可以用从官方上下载稳定版本的代码, 不要去GitHub直接拉默认的工程有几个路径和宏之类的不对, 小改一下就可以如果缺文件, 可以到GitHub的历史版本里去找编译好了就一个lib, 一个dll, pdb看需要环境配置C++这边肯定要链接mono.lib, 所以dll要拷贝到exe的目录除了mono本身外, 还需要.net的runtime assembly, 最精简的情况

网格最大是32x32的地形块(按WOW的习惯, 叫做Chunk)每个Chunk是8x8的格子, 每个格子是一米纹理最大支持8层纹理混合, 带NormalMap地形纹理都是1024x1024的DXT5格式混合权重图是2048x2048的A4R4G4B4格式, 估计整个地图使用两张(8通道)可能是使用了延迟渲染的原因, 地形的纹理都是先混合成一张Diffuse和一张Normal后再画镜头近时使用1024x1024的Diffuse RTT, 512x512的Normal RTT远处使用512x512的Di

前段时间在看wow的模型的时候, render flag中有一个很奇怪的渲染状态切换, 而且这个状态在WoWDev上也没有被提及. pass.useEnvMap = (texunitlookup[tex[j].texunit] == -1) && ((rf.flags & 0x10) !=0) && rf.blend>2; //&& rf.blend<5; // Use environmen

基于StormLib, 参考N3的ZipFileSystem实现了一个MpqFileSystem 有一点要注意, 文件路径里不能用/, 都要用// @_@ mpq文件包里的文件是不保存文件名(或目录名)的, 也就是说打包后的文件是不可逆的. 但是在每个文件包的根目录下都有一个(listfile)文件, 里面包含了文件包中的文件名列表(为什么listfile文件最后有一段

上次画的刀因为是装备, 所以有多种颜色的纹理而多种颜色的纹理都要去查表...虽说DBC文件很简单, 但现在懒得看找个单一纹理的弄吧, 纹理名全存在M2文件里的随便看了看, 觉得这头蓝龙挺帅的, 就它了这次除了Mesh正好可以研究下Animation目标:2009/3/15: 模型+纹理绘制没有进行渲染状态的管理, 比如alpha test/blend切换

记录一下, 方便查阅官方链接: The StormLib library //----------------------------------------------------------------------------- // Functions in StormLib - compatible with Storm.dll // Typedefs for func

没怎么玩WOW, 不知道这刀叫什么名字. 于是乎我给起了一个代号: "秒大刀"(我朋友的网名@_@)这是ModelViewer里的效果, 也是俺努力地方向: 2009/3/2: 实现Mesh绘制其实这个很简单, 先把ModelHeader从文件里读出来, 根据顶点偏移和顶点数量读取到顶点信息, 创建VertexBuffer.再根据ModelView信息(传说是LOD

M2文件中的信息大体是这样的全局纹理列表 全局顶点列表 Position Blend weights Blend indices Normal Texture coordinates LOD (每个模型共4级?) Vertex indices (这级LOD用到的顶点 为全局顶点列表的索引) Face indices (每个三角形有三个, 同样

.BLP files are texture files used in games made by Blizzard Entertainment, also used in other games like Neverwinter Nights. While Blizzard provides an Interface AddOn Kit for extracting the user inte

天啊, 自己解析(listfile)本身就是一个错误!因为StormLib在打开MPQ文件时就已经自己解析过了, 没必要多此一举!而且, 虽然自己缓存一下文件树会加快查找和枚举的速度, 但是, 从字符串构造这个棵树的时间太长了~~~这就导致了一个很严重的问题: 启动速度慢.......对于文件树, 游戏没有什么用, 因为游戏读文件时根本不管是什么目录, 你可以把目录也看是文件名的一

上次用解析字符串的方式来列举目录和文件, 速度太慢尤其像Common.mpq这样一个MPQ的listfile就几兆的情况下, 速度简直不能忍受再想想ZipFileSystem中的FileEntry和DirEntry, 我想它们是用来缓存文件目录树的吧在内存中进行查找肯定比读文件快, 更不用说去解析字符串了还是加入进去好了与Zip不同的是, 我没有把文件一次性读入内存. 因为

破优快云的文章编辑器太难用了, 传个图要累死. 以后在知乎写完再转过来: https://zhuanlan.zhihu.com/p/28471808关于游戏中的捏人系统, 很少有资料提到怎么做, 印象中只有《天涯明月刀》分享过. 前段时间关注了个VR资源分享的公众号, 经常推送HS的捏人作品, 所以才引发了我的好奇心, 决定一探究竟.HS之所以能够有这么强的定制能力, 是因为第三方MOD工具的存...