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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這也很好的解釋了

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學(xué)長正在做的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的關(guān)鍵嗎val.first。

TC++PL 17.4.2
關(guān)于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;
}

關(guān)于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條
盡量使用最小的操作集合，以取得最大的靈活性

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

標(biāo)準(zhǔn)庫容器中的元素必須可以復(fù)制
在使用 noncopyable 的時候應(yīng)該注意這一點