|
|
最近数月一直受困于实现wow中人物碰撞反应的问题,试过多种解决方案而一直不能解决,所以结论是在根本思路上有问题.
一个完整的碰撞反应效果需要一个完整的物理引擎,一个完整的物理引擎如一个完整的图像渲染管线,不是我现在的能力所能到达的.
前面的碰撞检测库实际上不能达到商业级应用标准,技术上还是太小儿科,所以只能依靠现有商业级的物理引擎.
三大物理引擎Ipion,Metoolkit,Havok GDK, Havok收购了Ipion,所以相信Havok的引擎现在是最好的,XBOX都使用其SDK.
Ipion在Halflife2泄漏代码中有,Metoolkit也google的到文档,看来要推倒原有设计重来,从Metoolkit开始.
Wow的渲染引擎是同时支持固定渲染管线渲染和Shader渲染管线渲染的.
bls文件是wow的shader文件,分析它的实现可以学习引擎是怎样渲染的,以及如何做一个兼容固定管线和Shader管线的引擎.
bls里存储的是OpenGL low-level shading language的指令,terrain1.bls,terrain2.bls,terrain3.bls,terrain4.bls分别对应渲染一块具有1/2/3/4层的纹理地形.terrain1_s.bls,terrain2_s.bls,terrain3_s.bls,terrain4_s.bls分别对应渲染带高光反射的地形,其对应使用的是带有_s的地形纹理.
虽然shader可以按任何算法和顺序来混合使用各层纹理,但Wow的shader的使用仍受限于与固定管线的兼容,使用ARBfp1.0标准,仍然是按标准纹理层次先后叠加.从使用的纹理可以看出,
layer0Texture,layer1Texture,..,,blendTexture,其中blendTexture的每一个分量都是一个Alpha图,
地形块为3层纹理时,第一层直接渲染不需要Alpha图,第2,3层各需要一张Alpha图,即共需2张Alpha图,这2张Alpha图存储在BlendTexture的x,w分量上.
使用4层纹理时,使用BlendTexture的x/y/w作3张Alpha图.
由于最多有4层地形纹理,BlendTexture的z就剩下来作为阴影图使用,完成了整个地形块的Shader.
我的一位朋友跟我说最近他找工作被刷了几次,他的技术在我看来是好的,于是我说能不能进一家公司大多靠运气.
我确是这样认为的,一个人的能力是很难判定,招聘面试这种东西在我看来撞运气的成分偏多.
我快毕业时为自己准备了两份求职书,一份做会计的,一份做程序的,我在招聘会上投简历时,有几家计算机公司根本不收我的简历,说他们不收非计算机专业的,所以后来我在简历的专业一栏特别加个括弧,标明(非计算机系专业).
我第一次面试是一家搞网络媒体视频的公司,那时我除了C++什么都不知道,被问的一愣一愣的,回来马上买了3卷本TCP/IP协议书开始学,一直学到现在.
我实习时的公司,是因为那个招聘的主程和我一样是学金融管理的,我跟他和另一个程序侃了一下午的设备驱动程序开发,API Hook技术,现在想想真是好玩.
我毕业找工作,面试一个大公司,面试复试了3次,连技术经理都见了,最后是笔试,一张标准的学校里的C/C++考卷,考的都是古怪的语法,刻意考倒人的问题,我随便abcd了几下就答完了,马上被告知我不适合他们的公司.
然后又去了一家公司,一个刚当上部门经理的程序员面试我,问了几句后,要我用VC++上机写一个地图数据显示程序,我说时间不够啊,而且没有MSDN,写不出来的,他说没关系,随便写写,最后我倒是写出来了,不过图画颠倒了,当天晚上他就通知了我明天上班.于是我就跟着这个东北人混了几年,我问他为什么能招我,他说我说话很狂有点意思,我说我那么谦虚的一个人啦.他是很好的程序员管理人才,脾气好,东北人,又不计较什么,于是我的技术从此就开始直线上升.我开始学OpenGL是因为他说我们的GIS项目能不能用OpenGL来渲染,我研究了一个月结论是不能,因为水平不够,然后一头扎进3D的世界不回头了.他结婚我替男方收的礼金,他去了北京,走的时候大家在一起吃了好几顿饭,喝了很多酒,然后我也离开了公司做游戏去了.
而后的在msn上的面试只谈了半个小时,问了些基本的却是很关键的C++设计模式和多线程同步概念问题,马上就定下来了,感觉真是很爽,当时颇有些得意,事后想想却也只是destiny,而再往上又能去哪?
所以,面试这种东西,大多只是destiny,跟你的技术无关.或许有不可知论的味道,但我认为如此.
图像使用2次方是很讨厌的问题,不在技术难度上,而在技术妥协上.实际上要求美工作出2次方纹理,并且整张图的空间利用率要高,是很难的.
当有些策划丢过来奇奇怪怪的尺寸的图像,我都要吐血,当知道2n次方限制后,他们把图像尺寸扩大一下,再丢给我空余大量空白的2n次方纹理,再吐血.
玻璃渣资源里标准的2n次方人物纹理,图像挤的满满的,每个身体部位纹理还是一个矩形,利用率之高不得不令人佩服,然而这对美工要求是极高的.
1024*768的图像是要拆成4*3的256*256图像的,而不是一整大张纹理,因为768不是2的n次方,更不要扩大为1024*1024,加大25%的内存.
还有Wow里Loading界面的图像都压成512*512,因为Loading图像模糊一点不要紧,很简单却都是很重要的细节.
所以当Wow运行在我Geforce2的显卡上时,我觉的很cool.
Nvidia的驱动程序也很讨厌,实际Geforce6显卡才支持non power of two texture,Geforce 5200级的显卡,在硬件能力上不足以支持NPOT,但是最新的驱动程序使用了软件模式进行模拟支持,而软件模拟根本毫无实用价值,渲染变得超级缓慢,因为驱动程序每次纹理渲染都会很聪明地把非2次方尺寸图像自动Scale到2次方尺寸,对于一个800*600的图像,驱动程序在这个步骤就吃光了CPU.
所以总有些人喊着为什么OpenGL没有软件渲染支持,DX很体贴都有(实际上DX也没有,比如那个所谓的8层纹理),而我认为如果软件渲染能解决问题,那要硬件作什么!不能解决问题的方案我们支持它作什么!
// OpenGL动态执行2n次方图像限制
inline int next_p2(int a)
{
int rval=1;
while(rval<a) rval<<=1;
return rval;
}
int nWidthPowerOfTwo = next_p2(tex.nWidth);
int nHeightPowerOfTwo = next_p2(tex.nHeight);
if(tex.nWidth == nWidthPowerOfTwo && tex.nHeight == nHeightPowerOfTwo)
{
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, nWidthPowerOfTwo, nHeightPowerOfTwo, 0, ilGetInteger(IL_IMAGE_FORMAT), GL_UNSIGNED_BYTE, ilGetData());
tex.fScaleX = tex.fScaleY = 1.0f;
}
else
{
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, nWidthPowerOfTwo, nHeightPowerOfTwo, 0, ilGetInteger(IL_IMAGE_FORMAT), GL_UNSIGNED_BYTE, NULL);
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, tex.nWidth, tex.nHeight, ilGetInteger(IL_IMAGE_FORMAT), GL_UNSIGNED_BYTE, ilGetData());
tex.fScaleX = (float)tex.nWidth / (float)nWidthPowerOfTwo;
tex.fScaleY = (float)tex.nHeight/ (float)nHeightPowerOfTwo;
}
然而对这个问题,正确的解决方案是事先规划,强制执行,be clever.
Ufoz的WowMapViewer的sourceforge点被关掉了,这个是说明和及更新版本的下载点,WowModelViewer现在版本是0.47. http://www.pyoro.com/wowmapview.html程序About框上有linghuye的名字,pioneers,呵呵,低调,低调. 幸亏我有先见之明,存了以前的文档资料. http://www.cnitblog.com/Files/linghuye/Wowwiki.rar
乔治.吉辛（GEDRGE GISSING. 1857—1903）是英国小说家，散文家。他出生于约克郡的威克维尔特，在伍斯特郡的公谊会教派寄宿学校及曼彻斯特的欧文斯学院以优异成绩毕业。1876年因偷钱救助一个妓女犯了罪，被判处短期徒刑。后来，因朋友的帮助，被遣往美国，教语言课数月，在芝加哥过着穷困潦倒的生活，几乎濒于绝境当时他曾写过一些短篇小说投稿于《论坛报》。1877年返回英国后，还曾去德国学习哲学。虽然他是一个天赋很高，诚实、正直并有学问的小说家，但两次不幸德婚姻（第一个妻子因酗酒而悲惨地死亡），使他整个一生沦为写廉价小说的苦役者。吉辛的主要小说有《新穷士街》（1891）和《在流放中诞生》（1892）（该书中男主角葛德文?碧克有一部分是作者本人的自述），还有《古怪的女人》（1893）。贫穷对人的腐蚀作用是所有吉辛小说的主题。他既不相信有产者的慈悲，也不相信无产者的反抗，从而陷入悲观绝望之中。吉辛崇拜狄更斯，力图师承其风格。他写过《狄更斯研究》（1898），该书有其独特的见解。这本研究狄更斯的书，至今仍被认为是描写小说家的好书之一。但他并不同于狄更斯，在揭露与批判现实社会时，对改良社会不抱任何希望。在创作方法上，他继承了前辈文学大师对环境、人物的典型描写，又分析人物心理方面的特征。
《亨利.赖伊克罗夫特杂记》（即《四季随笔》），是1903年发表的一部半自传体性质的小品文集，是吉辛的散文代表作。日记中叙述一个隐士醉心与书籍、自然景色，与回忆过去生活。作者认为：生活与思想的乐趣，可以战胜已往悲哀的回忆。
以上摘自四季随笔中译本的序,我最喜欢的散文.每个知道一个整天坐在电脑前的程序员会喜欢古典音乐和文学,都会礼貌性地表示一下惊异.不同于贝多芬的高歌猛进,大喜大悲,永远保持昂扬的命运对抗和欢乐,吉辛是悲观的颓废的,两者我都喜欢,大俗近雅,悲剧的美体现了一种崇高性.散文四季随笔两者都不沾,追求平淡,欣赏自然,而这一切却也只是吉辛对自己想象中美好生活的描述,再次体现了吉辛的颓废,这种含意耐人寻味.
假设对该Socket依序连续发起两次以上的异步写操作,即发送数据,最终数据是否按顺序发出,客户端是否能按顺序收到数据?
1.书本的理论上异步IO操作不保证完成的顺序性.
2.实际测试运行数据消息是按序收到的,但实践没有100%的理论逻辑保证,程序有逻辑上的崩溃可能.
3.如果不能对TCP Socket进行连续异步写数据,且保证最终是有序的发送,那么Socket的异步完成端口没有实用价值.如果要等上次异步写操作完成,才能发送第2个数据,同步方式的方案最佳.完成端口的优势仅在其流量上.
4.假设用一个for循环连续发起1000次以上的异步写操作,意味着大量的系统资源被耗用,对服务器而言几千次很平常.
研究碰撞反应受阻,只好想些知识极限范围内的问题.
补:
发送顺序肯定和投递顺序一致的，这个是系统保证的，但完成通知的次序是不保证和投递次序一致的。- WINDOWS网络编程(第2版)
// 下段摘自网络论坛
其实在使用IOCP的时候，为每个SOCKET连接建立一个发送队列，发完一个包后才发第2个，这样从单个SOCKET来看，是成了阻塞的，但是从整个系统来看，比如你有1万个连接，那么对于单个连接来说，是不是组塞的问题都不大。因为当连接数多了后，你考虑的问题不是单个SOCKET要有多块，而是系统资源和带宽如何平均地分配给这么多个连接。
1.ACE主分2个概念群,基础模块和应用框架.卷1论述基础模块,卷2论述应用框架.采用模板的理念,使用基础模块类对应用框架类进行配置.
2.连接和通信的解藕.Acceptor/Connector -> SvcHandle
3.用7zip压缩源ace源代码形成2.86M的包,比rar的5.86M小了一倍,cool.
4.a.同步的多线程,多线程编程给软件带来的复杂度是量级上的,能避免就避免.
2.单线程反应式编程,同步反应,逻辑简单明确.
3.前摄器IO同步,由操作系统完成异步,优雅的逻辑,但仍显复杂,带来的好处也是很大
5.ACE的构架仍显过于地臃肿复杂,模式痕迹过重,不够小巧,以手工编码的TCP客户端编译28K,使用ACE框架的186K,差不多为6.5倍,为跨平台和灵活性付出了相当的代价.
6.前摄式和反应式天生本质逻辑的不兼容,使得Reactor和Proactor不能通过简单的代码配置进行变换,由于Proactor在逻辑上要求的更加灵活,使得Reactor这种强框架概念不再适应,Proactor在框架概念上变弱,但使得类交互更加复杂.
7.在框架方面对无连接协议UDP不兼容,使得框架的威力大减.
8.ACE中轻量级类很好用,简单且跨平台.
9.ACE_Message_Block很显然不能声明为堆栈或静态对象,只能在堆上创建,且没有编译时强制,这不好,程序员会写出完全错误的代码.
1.Wp64检测64位可移植性问题,导致warning( 4244,4267,4311,4312)
2.链接器 -> 优化 -> Windows98优化 去除,可省十几k.
3.msvcp60.dll和 msvcp71.dll是使用vc标准库时被连入的,即使使用了一个函数,也需要发布几百k的dll,非常的讨厌.对于Vc.net2003可以使用#define _STATIC_CPPLIB静态链接msvcrp.dll,消除dll引用.VC6需要改动内部实现代码,没有好的解决手法.若一个静态库使用了_STATIC_CPPLIB,所有使用该静态库的程序必须也使用_STATIC_CPPLIB,否则链接出错(链接纯C库没有这个问题).应该保证让_STATIC_CPPLIB作用到所有使用到c++标准库的cpp文件.
4.程序无法启动,编译新旧文件杂揉原因导致C库混乱,如应当编译出错的文件被编译过了.
5.Solid_D.lib(BP_Scene.obj) : warning LNK4204: “f:\Gamedev\Objs\DestinyMatrix\D\vc70.pdb”缺少引用模块的调试信息；正在链接对象，如同没有调试信息一样
Solid_D.lib(BP_Scene.obj) : warning LNK4204: 'f:\Gamedev\Objs\DestinyMatrix\D\vc70.pdb' is missing debugging information for referencing module; linking object as if no debug info
LNK4204是个很含糊的warning,也很讨厌.MSDN上说是f:\Gamedev\Objs\DestinyMatrix\D\vc70.pdb文件是损坏的,要求重编,谬之甚已.上文的实际意思是找不到Solid_D.lib编译对应的vc70.pdb,比如Solid工程被Clean了.Solid_D.lib里有其对应的vc70.pdb的绝对路径,所以Solid_D.lib可以被复制到任何工程目录,而调试时IDE能找到lib对应的调试信息.一旦其对齐的vc70.pdb被删除就出现LNK2404.
IDE的工程Clean也有问题,它的Clean不是严格Clean指定工程的中间文件,而是Clean掉工程的中间目录,如果设定多个项目的中间目录为一个目录,且相互依耐,编译就会出现问题,编译完全紊乱.特别是vc70.pdb只剩下最后一个被编译的工程的.
copy "$(TargetPath)" F:\Gamedev\Libs\
中间有空格的TargetPath要加上"",否则空格导致copy失败
在一类构造函数中m_nLen = 0;这样一条初始赋值语句运行后,在我眼皮子底下,朗朗乾坤,光天化日下,m_nLen竟然仍然等于0xcdcdcdcd,赋值语句无效!!!
Clean工程,删除中间文件,重启机器,重装Vc6, m_nLen仍然死活不能赋值为0,吐血五升,天龙五衰之兆啊.
折腾了一整天后,终于发现,是预编译文件stdafx.h,stdafx.cpp,及m_nLen=0;所在cpp的预编译配置有些小问题.使用automaticlly use of precomopile file竟然会出现这种毫无因果的问题,真是衰透了.
改成使用指定的stdafx.h预编译头文件了事.
不由哀之,生活中亦凡有此种Bug,毫无因果,却足以让你为之付出沉重的代价.人生之不堪承受也如是.
|