C++博客-琴弦上的熊http://www.cppblog.com/gemfeeling/Machine should work, people should think...zh-cnSun, 05 Apr 2026 16:41:50 GMTSun, 05 Apr 2026 16:41:50 GMT60姗姗来迟的 Boost 1.34http://www.cppblog.com/gemfeeling/archive/2007/05/13/24044.html琴弦上的熊琴弦上的熊Sun, 13 May 2007 08:56:00 GMThttp://www.cppblog.com/gemfeeling/archive/2007/05/13/24044.htmlhttp://www.cppblog.com/gemfeeling/comments/24044.htmlhttp://www.cppblog.com/gemfeeling/archive/2007/05/13/24044.html#Feedback0http://www.cppblog.com/gemfeeling/comments/commentRss/24044.htmlhttp://www.cppblog.com/gemfeeling/services/trackbacks/24044.html        漫长的等待之后，Boost 1.34终于浮出水面。趁着下载的时间，看看这次 boost.org 带来了哪些大礼吧！
       
        Foreach Library 用于简化对一个序列中的所有元素进行迭代（比 std::for_each 更优雅哦，Simplicity is Beauty 嘛 ）。
       
        StateChart Library 用于简化任意复杂度的状态机的实现。这应该是游戏开发者的福音了。相比于从前用晦涩的 C Macro 来实现一个简单的状态机语言，这个库强调了“easily readable and maintainable C++ code”。唯一疑问是，不知此库性能如何，有待来日细查。
       
        Typeof Library 相信大家对新标准中可能出现的 typeof 和 auto 这两个关键字一定很期待吧。这里 boost 提供了 typeof 和 auto 的库实现，在新标准普及前的很长一段时间，我们可以先用它们减少击键次数(当然，还是关键字来得踏实:))
       
        Xpressive Library 提供了更高阶的正则表达式支持。此库融合了 boost.regex 和 Spirit Parser Framework 的优点。以 C++ 表达式来编写正则表达式，好处是可以在编译期获悉语法的合法性，而且以这种方式表达的正则表达式可以互相引用，不像原先的 boost.regex， 只能在运行时进行语法检查和各种处理。
       
        最后的重头戏应该是众望所归的 std::tr1 了。虽然等到大众普及至少还要两三年，但想想这些即将标准化的词汇就让人心动（Reference Wrappers, Smart Pointers, result_of, Function Object Binders, Polymorphic function wrappers, Type Traits, Random Number Generators and Distributions, Tuples, Fixed Size Array, Hash Function Objects, Regular Expressions, and Complex Number Additional Algorithms.）
       
        此外还有不少原有库的更新，这里暂不细表。我这儿已经下载完毕，大快朵颐去也:)

琴弦上的熊 2007-05-13 16:56 发表评论
]]>场景管理 —— 由关卡设计师控制场景复杂度和逻辑相关性http://www.cppblog.com/gemfeeling/archive/2006/07/26/10541.html琴弦上的熊琴弦上的熊Wed, 26 Jul 2006 07:56:00 GMThttp://www.cppblog.com/gemfeeling/archive/2006/07/26/10541.htmlhttp://www.cppblog.com/gemfeeling/comments/10541.htmlhttp://www.cppblog.com/gemfeeling/archive/2006/07/26/10541.html#Feedback1http://www.cppblog.com/gemfeeling/comments/commentRss/10541.htmlhttp://www.cppblog.com/gemfeeling/services/trackbacks/10541.html 关于场景管理有了一些头绪，总算走出了被“选用哪种形式的场景管理”所困扰的烦恼。认识到场景的组织最关键的是应该以“逻辑层次+几何结构”来组织。加速渲染，对象剔除，碰撞检测都只是场景所应具有的功能，应该在不同的层次上区别的处理，而不能单纯的指望用一个“最优”的场景管理数据结构或算法来通吃。
 当前的处理方式是用树来维持所有对象（层次间的关系以逻辑为主，几何结构为辅），每个节点上存储变换矩阵(LocalToWorld & WorldToLocal)渲染场景时从根节点起遍历场景树，每得到当前节点时都通过它的变换矩阵得到局部坐标系。
 最重要的是这个场景树对关卡设计师而言一定要是可随时进行观察调整以及一定程度上的性能评估的，由于场景对象间的逻辑在程序引擎中很难管理(这些往往是由游戏设计师和关卡设计师共同拟定的)，所以场景树的结构管理权大部分应当由程序员转交至具体关卡的设计者。这样一是便于关卡设计师根据场景的复杂度和性能评估随时调整，二是便于后期针对特定的场景进行特定的优化，
 最重要的一点是任意的节点与其所有子节点都成了逻辑相关的，逻辑相关的好处在于“对某个节点进行变换能够立刻应用于它的所有子节点”在大部分情况下都是合适的，因为需要一起变换的对象往往都是逻辑相关的。这样就免去了关卡设计师常常需要把某些对象并为一组一起移动的麻烦。打个生动点儿的比方，在即时战略中，所有的兵种由于不是逻辑相关的，所以我们需要用Ctrl+1,Ctrl+2等将其分队，将对所有对象的独立操作简化为组操作。但是如果所有的军队根据上下级所属关系成为逻辑相关的层次结构，我们只需选中一个连长就可以操作该连的所有单位，而选中司令则可以处理整个军队，这样对关卡的设计者而言显然效率有极大的提高。
   
 关于游戏内建的编辑器，也有了一些想法，不一定所有的信息都需要在hud上显示出来，这样既麻烦也不便于显示和修改。改进的办法是在游戏外另开一个Editor窗口专用于显示信息和修改信息，比如选中对象时显示和修改被选中对象的信息，显示和修改场景树的节点间层次关系，等等。这样最大的受益者是拥有双显示器的关卡设计师。他们可以在一个屏幕上全屏运行游戏，而在另一个屏幕上修改场景树的属性。
 


琴弦上的熊 2006-07-26 15:56 发表评论
]]>