http://blog.csdn.net/noslopforever/category/25888.aspx学习中总有心得，心得记下来或许是一种好习惯吧。以后总会用得着的，哪怕是批判也总有了批判的对象，嗯嗯，或许会对别人也有所作用，呵呵。 由于心得都是想之即来的东西，必有其误，欢迎拍砖哦。^_^zh-CNSun, 02 Mar 2008 21:11:00 GMT60noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2008/03/01/2137281.aspxSat, 01 Mar 2008 13:48:00 GMThttp://blog.csdn.net/noslopforever/archive/2008/03/01/2137281.aspxhttp://blog.csdn.net/noslopforever/comments/2137281.aspxhttp://blog.csdn.net/noslopforever/archive/2008/03/01/2137281.aspx#Feedback0http://blog.csdn.net/noslopforever/comments/commentRss/2137281.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=2137281 一个引擎对于项目的普适性或许是更加重要的，我总这么认为。一个oo的企业框架已经能供各种各样的企业去完成自己的功能，为什么一个oo的游戏引擎却还是只能消化一两种游戏类型？这个很让人觉得愤懑。都说搞游戏的开发者都是一帮牛人，可我真的没有觉得在结构设计上，我们到底比那些企业项目的设计师们牛到哪里去。即便是某些自诩oo的引擎，也走的是那种强奸民意的自以为oo路线，一件事情只要不准备发生在它的体系下，那么这套体系就变得一塌糊涂，甚至一无是处了。在这上面，这些oo引擎和我们现在用到的这个不自我标榜oo的几乎是一丘之貉，只不过更小更精悍更底层，不会遇到像我们现在的问题罢了。oo有时候并不是简简单单的模式，而是模式之外，对于整个体系结构的清醒认识。——这上面ogre做得还算可以，只可惜底层的设计上走得有点远，离一个游戏引擎差得也还太远了…… <img src ="http://blog.csdn.net/noslopforever/aggbug/2137281.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/12/22/1958256.aspxSat, 22 Dec 2007 09:46:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/12/22/1958256.aspxhttp://blog.csdn.net/noslopforever/comments/1958256.aspxhttp://blog.csdn.net/noslopforever/archive/2007/12/22/1958256.aspx#Feedback3http://blog.csdn.net/noslopforever/comments/commentRss/1958256.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1958256当然，如往常一样，本文并不想引起什么纷争，C/C++还是我最为钟爱的语言，因为她纯粹。甚至我自己如果写程序，首先考虑到的决不会是CLI Wrapper和COM Wrapper，而一定是把我自己的程序做成C Wrapper，因为这样能支持更多的语言（理论上）。 但是，这并不意味着一切就可以就此止步，引擎中20%的代码是为了效率，但还有80%的代码是为了方便，这20%的致命一层，目前仍然必须借助C/C++进行呵护，而那80%的工具、编辑器、框架，或许我们更应该为用户考虑，用户方便，那就是方便，用户痛苦，那就是痛苦。有时候，在这个层次上，C++的表现确实是一场灾难。那么，如果有更灵活的语言，为什么不去尝试呢？ <img src ="http://blog.csdn.net/noslopforever/aggbug/1958256.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/09/21/1795302.aspxFri, 21 Sep 2007 20:58:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/09/21/1795302.aspxhttp://blog.csdn.net/noslopforever/comments/1795302.aspxhttp://blog.csdn.net/noslopforever/archive/2007/09/21/1795302.aspx#Feedback0http://blog.csdn.net/noslopforever/comments/commentRss/1795302.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1795302用了一个乱八七糟的模型，计算出来的浮点数据都是带e的，头疼无比。初衷或许是好的，就是希望这种很普通很普通的模型如果都对了，那么其他的应该自然不在话下。可是在这种模型上，数据成了这样，对错真的很难判断。结论，应该从小到大发现问题，先用标准的，特殊的模型去把一些细微功能排除掉，再用一般的，普通的模型，检测更多的问题。但是，在Matrix计算完毕后，不知道自己当时怎么想的，又把这个Matrix做了一次inverse……<img src ="http://blog.csdn.net/noslopforever/aggbug/1795302.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/08/20/1752133.aspxMon, 20 Aug 2007 22:50:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/08/20/1752133.aspxhttp://blog.csdn.net/noslopforever/comments/1752133.aspxhttp://blog.csdn.net/noslopforever/archive/2007/08/20/1752133.aspx#Feedback2http://blog.csdn.net/noslopforever/comments/commentRss/1752133.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1752133但现在，我开始相信，一个完善的中间层，势必需要一个个功能独立，结构完善，接口明晰的底层模块的建立——这并不简单的在说那些VB/IB/Camera之类的东西。地形、空间、场景结构，我曾将之勾画到场景的核心之中，但带来的结果，除了使中间层的场景变得僵化之外，还迫使很多不必要的东西，被迫由这些本来应该简单而短小的模块去承受不该它们承受，它们也无法承受的重量。交给中间层吧。将一个完整的中间层作为你能发布的东西，但是，更底层的，引擎的核心，保留一些自由、僵直、自封闭、透明的孤立的功能点，或许是更好的设计？<img src ="http://blog.csdn.net/noslopforever/aggbug/1752133.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/07/20/1700382.aspxFri, 20 Jul 2007 14:04:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/07/20/1700382.aspxhttp://blog.csdn.net/noslopforever/comments/1700382.aspxhttp://blog.csdn.net/noslopforever/archive/2007/07/20/1700382.aspx#Feedback1http://blog.csdn.net/noslopforever/comments/commentRss/1700382.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1700382……只是希望，切莫再有一个愚蠢的声音告诉我们：“数学就是算法，算法就是一切……”。算法离不开工程，就正如工程离不开算法一样，一两个核心算法的效率考虑，很可能关系到整个工程核心模块的结构组织，再松耦合的工程设计也不可能做到对逻辑的无关耦合。底层的工具、硬件结构和API决定了算法，算法关系着工程的核心结构，对工程的核心结构的设计也反过来影响算法的实现。认为（所谓的）算法高于工程结构，和认为工程结构高于算法的想法，都太脱离实际了。<img src ="http://blog.csdn.net/noslopforever/aggbug/1700382.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/06/30/1672787.aspxSat, 30 Jun 2007 19:16:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/06/30/1672787.aspxhttp://blog.csdn.net/noslopforever/comments/1672787.aspxhttp://blog.csdn.net/noslopforever/archive/2007/06/30/1672787.aspx#Feedback6http://blog.csdn.net/noslopforever/comments/commentRss/1672787.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1672787而且就现在而言，游戏的类型可以千变万化，场景的组成模态无非就那么几种：MMORPG肯定会首选Portal＋四叉树室外地形，休闲类网游甚至可能都没有复杂的场景管理：赛车什么的一般都是室内BSP，更有甚者，可能干脆都不需要场景管理。如果您觉得这只不过是危言耸听，那可以自己去试一试，如果你能做得到在OGRE的四叉树、OGRE的BSP和OGRE还未出现的八叉树中加入互相之间的Linker以组成一个一般的MMORPG需要的引擎的话，那算我什么都没说——注意这个抽象的Linker需要考虑到各种可能的升级的情况，更要考虑到增加了其他场景类型的情况。……<img src ="http://blog.csdn.net/noslopforever/aggbug/1672787.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/06/24/1664432.aspxSun, 24 Jun 2007 12:24:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/06/24/1664432.aspxhttp://blog.csdn.net/noslopforever/comments/1664432.aspxhttp://blog.csdn.net/noslopforever/archive/2007/06/24/1664432.aspx#Feedback0http://blog.csdn.net/noslopforever/comments/commentRss/1664432.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1664432今早起来，大约是很久没睡得这么死猪的缘故，头有点朦朦的，趁着朦朦的劲头一口气逛了一大堆一大堆的Blog，有同学的，朋友的，还有一大堆不认识的；编译期猜掉函数、方法、成员的类型和参数类型，一方面，不得不佩服Template的强大，另一方面，不得不鄙视一下C、C 这类偏底层语言，其实很多事情，编译期都是知道的，需要的就是通过一些方法把它们导出来让程序员知道，使得程序员可以在编译期就决定很多事情，而不是落后到了运行时再去决定——况且，对于C ，运行时还有很多事情是没法决定的，不是么？<img src ="http://blog.csdn.net/noslopforever/aggbug/1664432.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/06/14/1652495.aspxThu, 14 Jun 2007 16:08:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/06/14/1652495.aspxhttp://blog.csdn.net/noslopforever/comments/1652495.aspxhttp://blog.csdn.net/noslopforever/archive/2007/06/14/1652495.aspx#Feedback0http://blog.csdn.net/noslopforever/comments/commentRss/1652495.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1652495不废话了，很多很多事情要做，三头六臂估计不够，可能得来个八臂罗汉千手观音什么的。 那个，老样子，继续欢迎拍砖手雷扔炸弹。 <img src ="http://blog.csdn.net/noslopforever/aggbug/1652495.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/06/13/1650291.aspxWed, 13 Jun 2007 12:32:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/06/13/1650291.aspxhttp://blog.csdn.net/noslopforever/comments/1650291.aspxhttp://blog.csdn.net/noslopforever/archive/2007/06/13/1650291.aspx#Feedback1http://blog.csdn.net/noslopforever/comments/commentRss/1650291.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1650291Boost的File system确实很好用，而且据说是跨平台的，由于我几乎从来没在Linux下打开过编译器（大家可以尽可能鄙视我，谢谢），所以我也不知道具体怎么回事，但是好用确实是好用。考虑到Boost其他库中基本都是提供的template string版本，这个瑕疵真的让人觉得很遗憾。粗略看了下文档，关于这个，Boost File System似乎不认为是个问题，连个描述都没给，希望Boost以后的版本能对这个问题起码提出个说法。<img src ="http://blog.csdn.net/noslopforever/aggbug/1650291.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/06/05/1638536.aspxTue, 05 Jun 2007 09:07:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/06/05/1638536.aspxhttp://blog.csdn.net/noslopforever/comments/1638536.aspxhttp://blog.csdn.net/noslopforever/archive/2007/06/05/1638536.aspx#Feedback1http://blog.csdn.net/noslopforever/comments/commentRss/1638536.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1638536本Blog原来那篇《智能指针三兄弟》，在智能指针的使用上，使用了侵入式的设计。欲使用智能指针，则必须为每个使用智能指针的类生成一个static的INVALID对象。如果是自己写一个库自己用那大凡没有问题，但如果用在别人的库上，这就吃亏了。本文给出了一个非侵入式的思路来解决这个问题。<img src ="http://blog.csdn.net/noslopforever/aggbug/1638536.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/05/31/1632676.aspxThu, 31 May 2007 13:15:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/05/31/1632676.aspxhttp://blog.csdn.net/noslopforever/comments/1632676.aspxhttp://blog.csdn.net/noslopforever/archive/2007/05/31/1632676.aspx#Feedback8http://blog.csdn.net/noslopforever/comments/commentRss/1632676.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1632676 嗯，好吧，不废话了，还有很多问题要解决，继续。 欢迎拍砖扔炸弹。 ^_^ <img src ="http://blog.csdn.net/noslopforever/aggbug/1632676.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/05/25/1625882.aspxFri, 25 May 2007 17:24:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/05/25/1625882.aspxhttp://blog.csdn.net/noslopforever/comments/1625882.aspxhttp://blog.csdn.net/noslopforever/archive/2007/05/25/1625882.aspx#Feedback5http://blog.csdn.net/noslopforever/comments/commentRss/1625882.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1625882 目前的构架还是太乱，抽时间需要整理一下。开始放图，老样子，欢迎拍砖，扔炸弹。 下面的任务就是纹理和光照图了。另外就是界面的工作，把PropertyGrid都填上，Output也开始填上。祝我好运吧。 <img src ="http://blog.csdn.net/noslopforever/aggbug/1625882.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/05/21/1619949.aspxMon, 21 May 2007 22:57:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/05/21/1619949.aspxhttp://blog.csdn.net/noslopforever/comments/1619949.aspxhttp://blog.csdn.net/noslopforever/archive/2007/05/21/1619949.aspx#Feedback1http://blog.csdn.net/noslopforever/comments/commentRss/1619949.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1619949去年做C#的时候，已经颇感觉到.NET的强大了，只不过VC .net一直让我很不爽：不知道是我自己不会还是别的什么原因，VC .net与原生C 的融合我一直难得其法。强大！只要写了property，那么PropertyGrid控件的一个方法就可以让被关注类的所有property一览无余地显示在控件里——两句话的问题。这个就不说了，另外，WenFen Luo的Docking控件，虽然用的是C#，但是可以很方便地放到CLI的工程里使用，它可以几乎以假乱真地模拟Visual Studio 2005的界面——包括对各个Docking Panel的拖拽操作，还有啥好说的呢？<img src ="http://blog.csdn.net/noslopforever/aggbug/1619949.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/05/15/1610377.aspxTue, 15 May 2007 18:20:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/05/15/1610377.aspxhttp://blog.csdn.net/noslopforever/comments/1610377.aspxhttp://blog.csdn.net/noslopforever/archive/2007/05/15/1610377.aspx#Feedback9http://blog.csdn.net/noslopforever/comments/commentRss/1610377.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1610377每个Block最大4张纹理，4张纹理使用一个“Blend Light”Map（后面简称BLMap）进行混合，T1-T2、Result12-T3、Result123-T4的Blend因子分别是BL.R，BL.G和BL.B。分别实现了PS11的4 Sampler版（也就意味着4张纹理时会用到2Pass）和PS2X、PS30的16Sampler版（基本上都是1个Pass）。其实PS14的6Sampler版也应该做，因为4纹理在这个版本正好可以1个Pass渲完。<img src ="http://blog.csdn.net/noslopforever/aggbug/1610377.aspx" width = "1" height = "1" />noslopforever（天堂里的死神）http://blog.csdn.net/noslopforever/archive/2007/04/06/1553703.aspxFri, 06 Apr 2007 09:02:00 GMThttp://blog.csdn.net/noslopforever/archive/2007/04/06/1553703.aspxhttp://blog.csdn.net/noslopforever/comments/1553703.aspxhttp://blog.csdn.net/noslopforever/archive/2007/04/06/1553703.aspx#Feedback0http://blog.csdn.net/noslopforever/comments/commentRss/1553703.aspxhttp://tb.blog.csdn.net/TrackBack.aspx?PostId=1553703曾让我郁闷的东西我总是想解决，Locale也算其一。前天看了看VC8：CRT的Src，终于搞明白了face_t::codecvt的大致流程，中间也有一些问题，隐隐约约感觉到操作系统作了一些我们所不知的事情，还有一些高不太明白地事情，要在以后慢慢看了。最后的CodeConvert本身是很简单的——就是调用了Win32的MBtoWC和WCtoMB那两个函数。写得很经典，有时间再好好看看。希望能尽快形成文档，整理一下思路～～ <img src ="http://blog.csdn.net/noslopforever/aggbug/1553703.aspx" width = "1" height = "1" />