說明一下 monkeyispig.com 是本人自己的blog，發(fā)在cppblog只為增加人氣 ：）所以沒有全文轉(zhuǎn)載，轉(zhuǎn)個引子請大家點擊一下：

     摘要: 新手在剛接觸一些實際項目的遺留代碼時會覺得很迷茫（比如我）。相信過來人都知道這種感受——代碼量大、注釋少、難讀懂。這只是最膚淺的認識，隨著接手任務需要在代碼上做添加和修改的時候那就真的是更難以下手了。一方面是對代碼不熟悉，另一方面則是代碼已經(jīng)被修修補補得十分混亂了。  閱讀全文

     摘要: 場景管理是游戲中非常重要和基礎的部分，初次接觸場景管理是使用了Ogre中的場景管理器(SceneManager)。其中的場景節(jié)點(SceneNode)便是非常好用的一套用于表示場景位置關系的抽象。縱觀Ogre的實現(xiàn)，SceneNode是繼承與Node類，Node類則主要實現(xiàn)了空間位置關系的操作。

在2D游戲中，同樣需要一套猶如SceneNode的場景管理節(jié)點，那么如何實現(xiàn)和設計一套用于2D的節(jié)點來調(diào)整空間關系呢？
  閱讀全文

     摘要: PyOgre安裝以及如何使用Blender導出Ogre的Mesh。  閱讀全文

     摘要: 蠻喜歡這句話的，當生活中總是充滿了各種抱怨的時候，這句話總是讓人耳目一新。
當我們抱怨的時候，為什么不動手去改變它呢？有人說太遲了，what's done is done!
反過來思考這個問題，很多事情都已經(jīng)成了定局才讓我們抱怨和后悔，那之前做這些事的時候，或許就沒有用正確的方式來做才造成了現(xiàn)在的樣子。  閱讀全文

     摘要: vim, ctags, taglist 的一些基本使用方法的記錄～  閱讀全文

     摘要: 游戲主循環(huán)是每個游戲的心跳，輸送著整個游戲需要的養(yǎng)分。不幸的是沒有任何一篇好的文章來指導一個菜鳥游戲程序員如何為自己的程序供養(yǎng)。不過不用擔心，因為你剛好不小心看到了這篇，也是唯一一篇給予這個話題足夠重視的文章。

由于我身為游戲程序員，我見過許許多多的手機小游戲的代碼。這些代碼給我展示了五彩繽紛的游戲主循環(huán)實現(xiàn)方法。你可能要問：“這么簡單的一個小玩意還能做到千奇百怪？” 事實就是這樣，我就會在此文中討論一些主流實現(xiàn)的優(yōu)缺點，并且給你介紹在我看來最好的輸送養(yǎng)分的解決方案。  閱讀全文

     摘要: 今天實訓的某同學給我看了一段簡單的代碼，蠻有意思~數(shù)組不是越界了么？為什么結(jié)果還是正確的呢？  閱讀全文

問題是這樣的，這個“項目”經(jīng)歷了種種變更，目前需求定格在3D動作類游戲上。
在游戲引擎制作的過程中遇見了現(xiàn)在這樣的問題：

某從業(yè)人員即一位有經(jīng)驗的XNA開發(fā)者告訴我們小型游戲利用XNA來做會比較有效率（相對后一種方案）。
不過現(xiàn)在問題出在對.Net，XNA都不是十分熟悉，去使用XNA必然又比較大的學習代價。

后一種方案：使用OGRE+各種游戲引擎中還需要的其他類庫來做自己的游戲引擎
相對于.NET C# XNA，C++應該在語言的熟悉程度上更好一些
OGRE也接觸了一些，不算熟悉，但是也能了解基本運用
也就是后者可能在整合的方面會遇見一些更實際的問題，但是大體還熟悉

而前者XNA是一個不錯的游戲開發(fā)框架，但是卻需要付出學習代價

后者的問題…… 其實我也只是聽同學提到一個很模糊的說法：“在后期會遇見一些麻煩”
這個說法也是前文中的那位從業(yè)人員給我同學的說法。
而實際上，我更傾向于的是后面這種解決方案~
因為從自己的知識層面和項目組成員的知識層面上來說，C++還是比C#要熟悉一些
OGRE對于一個基本完全未知的XNA藥熟悉一些。

希望有相關開發(fā)經(jīng)驗的大大能夠來幫忙解決下心中的疑惑！到底是用XNA+.NET還是OGRE+C++
游戲規(guī)模是中小型，平臺現(xiàn)在由于各種原因限制在Windows上
這兩套解決方案到底孰優(yōu)孰劣？好又好在什么地方，缺點又有一些什么？
實際應用上，會出現(xiàn)很棘手的麻煩么？

我自己也深知在這種解決方案上去徘徊遠不如靜下心選定一個方案去解決現(xiàn)實世界的問題來得實際。
不過我自己心中有一個“潛選擇”，我怕前者真的是一套好的方案卻被放棄掉

希望各位大大支招，謝謝了~！

寫了幾天代碼，怕自己沒頭沒腦一直寫下去
還是乖乖的跑去圖書館看書

下面都是一些片段，都是自己覺得有意思的地方，所以還是記下來比較好

TC++PL 15.4.5
Object過于一般，因為它并不對應于應用領域中的任何抽象，還迫使應用程序員去使用一個實現(xiàn)層的抽象。解決這類問題的更好方式是使用容器模板，在其中只保存某一類指針……

TC++PL 15.5
然而，一個指向成員的指針并不像指向一個變量或者指向一個函數(shù)的指針，它并不是一個指向一塊內(nèi)存的指針。這種指針更像是一個結(jié)構(gòu)里的偏移量，或者到一個數(shù)組里的下標。

這也很好的解釋了

typedef (Class::*mem_fun_ptr)(argus..);
的mem_fun_ptr要和一個class的實體結(jié)合使用…… 就像把這個 偏移量 施加在這個 結(jié)構(gòu)體 上

mem_fun_ptr mfptr = &Class::one_mem_fun;

Class *p = new Class;
Class instance;

(p->*mfptr)();

TC++PL 18.4.4.1
注釋中的 Curring化 正是OwnWaterloo學長正在做的callback_curring ..

f(x,y) 看作 f(x)(y)

TC++PL 17.4.1末尾

std::map::inserat(val)返回std::pair<iterator,bool>
如果val被實際插入（可能由于已經(jīng)存在的key不能插入）那么bool為true。迭代器引用的是map中的一個元素，
它保存著val的關鍵嗎val.first。

TC++PL 17.4.2
關于multimap中查找某key得到的返回值

void print_numbers(const multimap<string,int>& phone_book)
{
    typedef multimap<string,int>::const_iterator I;
    pair<I,I> result = phone_book.equal_range("name");
    for (I i = result.first; i!=b.second; ++i) cout<<i->second<<endl;
}

關于tri的hash_map，boost是一個好東西
相對于utility pack來升級支持tr1使用boost反而有更好的移植性
#include <boost/tr1/unordered_map.hpp>

std::tr1::unordered_map<key_type,val_type> hashmap;

TC++PL 17章忠告中第10條
盡量使用最小的操作集合，以取得最大的靈活性

------------------------

標準庫容器中的元素必須可以復制
在使用 noncopyable 的時候應該注意這一點