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