Infinity 無限星辰，無限強大的科幻游戲啊，不過還遠遠沒有完成

如果SmallObject最大大小并不是很大的話~~也許可以根據對象大小弄成多個SmallObjectHeap。

比如對象大小是2，就放在SmallObjectHeap2，
對象大小是4，就放在SmallObjectHeap4，
對象大小是8，就放在SmallObjectHeap8.......

這樣就可以省去內存縮并的工作。只有當Heap不夠大時，才擴大內存。

不用執行碎片的方法（參考python的實現）：
struct BlockN
{
BlockN* m_Free;
char data[N];//大小為N的對象數據
}；
class SmallObjectHeapN
{
BlockN m_Blocks[size];
BlockN* m_NextFree;
};
SmallObjectHeapN的類里面有一個指向空閑地址的指針m_NextFree，每個BlockN也有一個指向空閑地址的指針m_Free（初始化成0），
在一開始的時候SmallObjectHeapN的m_NextFree肯定指向m_Blocks的地址；
添加的時候，發現m_NextFree所在的block里面的m_Free是0，于是++m_NextFree；
某個block刪除的時候，m_Free=m_NextFree，而m_NextFree指向這個被刪除的block；
再次添加對象時，發現m_NextFree指向的block里面的m_Free不是0，則添加完成后，m_NextFree=block->m_Free就行了。

學習了。
內存池整理時機的那個“閾值”弄成動態的，和“年老的對象”的數量成比例，效率應該比較好，純猜測....

不過感覺仍然有不足，兩個食物里面都要定義一個typedef

還是模板特化比函數容易想到~~

#include<iostream>
#include<string>
using namespace std;

struct Gooood{};
struct Baaaad{};

template<typename T>
class TasteFood
{
public:
static void Test()
{
cout<<"er...I don't know this smell,taste fail........"<<endl;
}
};

template<>
class TasteFood<Gooood>
{
public:
static void Test()
{
cout<<"this food tasted goooooooooood~~~~~"<<endl;
}
};

template<>
class TasteFood<Baaaad>
{
public:
static void Test()
{
cout<<"this food tasted baaaaaaad........."<<endl;
}
};

class Pizzzzzza
{
public:
typedef Gooood T_Tasted;
};
class FoodInSchool
{
public:
typedef Baaaad T_Tasted;
};

template<typename T>
void AfterEat(T&food)
{
TasteFood<typename T::T_Tasted>::Test();
}


int main()
{
Pizzzzzza food1;
FoodInSchool food2;

AfterEat(food1);
AfterEat(food2);

int a;
cin>>a;
return 0;
}

看不明白，RenderToTexture 是個負責干什么的對象。。。。

那個通道狀態“是否有貨”實際就是鎖，確實沒有同步起來

還真的不明白，這里說的物體的顯示是指服務端上要通知給客戶端顯示的物體？還有你說的單足物體和多足物體，還不明白是什么內容？

還是boost python、boost luabind強大啊，，，

視錐體和包圍球的碰撞計算量很可觀~

致謝并且封神~~~

位移只有float3，應該能又節約一些吧？
uniform vec4 g_allBonesQuaRot[50];
uniform vec3 g_allBonesTran[50];

期待下一篇，掛在材質上的人學習了

最近發現一個強大的大學生團隊的游戲
http://planetbad.cn/

蘋果的xcode也有一個叫Instrument的東西，橫向時間軸，豎向一些內存使用量、泄漏位置、函數調用開銷等等。。。總之看起來確實像Instrument

不過在蘋果上弄開發仍然是煎熬，效率低，svn垃圾........

坐等圖片

搶座位~~~

這個沒辦法解開的，邏輯復雜時，不可能 既完全沒有重復代碼，又效率最高（思路最清晰）的

覺得1、2種都可以

World TM是相對于整個場景的變換矩陣，Local TM是相對于父物體的，Object TM是相對于自身的。
還不太明白的是Object TM有什么用，難道除了單位矩陣還有其它值？

想起當年玩單機版的勁樂團.....

物理用10年，生命學用20年........

"應該先有應用，再提煉出庫。而不是先造庫，然后尋求應用。"

應該先有游戲，再提煉出引擎，而不是先造引擎，然后尋求游戲

看來我找到失敗的原因了

還沒有看過...

是不是沒有做文件系統的話，以后資源打包的問題上就杯具了？

在開發時，一般都是直接使用文件目錄下的資源，但到發布產品時，都要把這些資源文件夾打包成zip之類的，然后保持代碼改動最小。因此文件系統統一負責所有硬盤讀寫的操作，文件系統更主要的是這個功能吧？

太強了，依然保持看不懂的水平

培養興趣還是要靠環境啊，“學校只需要保證一個幾乎把自己所有的時間投入到代碼中去的人能夠找到合理的工作就好了”---學校保證這個不難，難的是如何幫助轉變越來越多這樣的人，學校對這方面的貢獻還是太小了...

當然這個和學生自己也有關系，比如我，讓博主白感化了幾年-_-!

今天弄蘋果開發，發現蘋果XCode的界面庫開發的內部機制和你這個是一樣的~~

厄...
先理解骨骼系統，實際是一棵（多棵？）層次樹，樹結點包含著變換矩陣，變換矩陣要建立在父節點的矩陣空間中
然后，蒙皮過程就是對那些受影響的頂點進行矩陣變換的操作....

還是先看書吧，我只是大概總結一下~

覺得有些步驟還寫得含糊欠妥，盡量改正....

“谷歌離開中國會讓我們的**與朝鮮、剛果金等被google拒絕服務的國家為伍”
.........

凸n邊型知道各頂點圍繞順序的話，向量叉乘最容易

關注中....

難以想象...

@zll
你說的初始化已經定義了視景體應該是指定義透視投影矩陣吧，opengl內設的裁剪只是面級別的裁剪，并以次剔除多余頂點。我們渲染時肯定要做更高一層的剔除，那些空間分割樹就是為了這方面優化而來的，上面那個LOD地形是4叉樹結構，當然能做“子物體級別”的裁剪，上面代碼373行就是。

學習了，目前在嘗試休閑的小游戲，按文章所說的用LCT，但仍然不時會小小延遲，于是也加了點慣性，這樣一來游戲是平滑了，但是操作反應和手感.....

以無架構為架構，乃構架的最高境界；以無pattern為pattern，乃設計模式的最高境界....哈哈

Effective c++還是more Effective c++就有說到這個

@陳梓瀚(vczh)

是啊，空閑時間學習學習，體驗體驗，有什么建議嗎？

很強大，接下來應該實現tuple了

樹的資源我也沒有，目前收集了不少太空飛船模型，可惜也是高模的，沒有美工確實是一個人學習時的大問題...

不過樹能不能用分型來實現呢，這樣算法可能很難，不過性能和效果應該很不錯，還可以LOD

整顆樹都是billboard也太節約資源了吧，一般都是一個樹枝上的葉子用一個四邊形

粒子混合還是不要用疊加好，很難控制亮度，也沒有了立體感

已更正，另外還有一處提示寫錯：

主鍵盤上0控制坐標X,1控制坐標Y,2控制坐標Z,3控制坐標W，以此類推

感謝各位提供資料，目前程序初步成功~

是不是VL_BEGIN_BASE_CLASS的話，VL_ADD_CLASS_MEMBER里面的內容類型一定要C++的基本類型？這樣對所有基本類型都進行特化？