漫長的等待之后，Boost 1.34終于浮出水面。趁著下載的時間，看看這次 boost.org 帶來了哪些大禮吧！
Foreach Library 用于簡化對一個序列中的所有元素進行迭代（比 std::for_each 更優(yōu)雅哦，Simplicity is Beauty 嘛 ）。
StateChart Library 用于簡化任意復雜度的狀態(tài)機的實現。這應該是游戲開發(fā)者的福音了。相比于從前用晦澀的 C Macro
來實現一個簡單的狀態(tài)機語言，這個庫強調了“easily readable and maintainable C++
code”。唯一疑問是，不知此庫性能如何，有待來日細查。
Typeof Library
相信大家對新標準中可能出現的 typeof 和 auto 這兩個關鍵字一定很期待吧。這里 boost 提供了 typeof 和 auto
的庫實現，在新標準普及前的很長一段時間，我們可以先用它們減少擊鍵次數(當然，還是關鍵字來得踏實:))
Xpressive Library 提供了更高階的正則表達式支持。此庫融合了 boost.regex 和 Spirit Parser
Framework 的優(yōu)點。以 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.）
此外還有不少原有庫的更新，這里暫不細表。我這兒已經下載完畢，大快朵頤去也:)
Jul.25, 2006
?關于場景管理有了一些頭緒，總算走出了被“選用哪種形式的場景管理”所困擾的煩惱。認識到場景的組織最關鍵的是應該以“邏輯層次+幾何結構”來組織。加速渲染，對象剔除，碰撞檢測都只是場景所應具有的功能，應該在不同的層次上區(qū)別的處理，而不能單純的指望用一個“最優(yōu)”的場景管理數據結構或算法來通吃。
?當前的處理方式是用樹來維持所有對象（層次間的關系以邏輯為主，幾何結構為輔），每個節(jié)點上存儲變換矩陣(LocalToWorld & WorldToLocal)渲染場景時從根節(jié)點起遍歷場景樹，每得到當前節(jié)點時都通過它的變換矩陣得到局部坐標系。
?最重要的是這個場景樹對關卡設計師而言一定要是可隨時進行觀察調整以及一定程度上的性能評估的，由于場景對象間的邏輯在程序引擎中很難管理(這些往往是由游戲設計師和關卡設計師共同擬定的)，所以場景樹的結構管理權大部分應當由程序員轉交至具體關卡的設計者。這樣一是便于關卡設計師根據場景的復雜度和性能評估隨時調整，二是便于后期針對特定的場景進行特定的優(yōu)化，
?最重要的一點是任意的節(jié)點與其所有子節(jié)點都成了邏輯相關的，邏輯相關的好處在于“對某個節(jié)點進行變換能夠立刻應用于它的所有子節(jié)點”在大部分情況下都是合適的，因為需要一起變換的對象往往都是邏輯相關的。這樣就免去了關卡設計師常常需要把某些對象并為一組一起移動的麻煩。打個生動點兒的比方，在即時戰(zhàn)略中，所有的兵種由于不是邏輯相關的，所以我們需要用Ctrl+1,Ctrl+2等將其分隊，將對所有對象的獨立操作簡化為組操作。但是如果所有的軍隊根據上下級所屬關系成為邏輯相關的層次結構，我們只需選中一個連長就可以操作該連的所有單位，而選中司令則可以處理整個軍隊，這樣對關卡的設計者而言顯然效率有極大的提高。
???
?關于游戲內建的編輯器，也有了一些想法，不一定所有的信息都需要在hud上顯示出來，這樣既麻煩也不便于顯示和修改。改進的辦法是在游戲外另開一個Editor窗口專用于顯示信息和修改信息，比如選中對象時顯示和修改被選中對象的信息，顯示和修改場景樹的節(jié)點間層次關系，等等。這樣最大的受益者是擁有雙顯示器的關卡設計師。他們可以在一個屏幕上全屏運行游戲，而在另一個屏幕上修改場景樹的屬性。
?