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，以此类推

@mybios
等我完成面的显示吧，目前只是显示线，效果有限

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

是不是VL_BEGIN_BASE_CLASS的话，VL_ADD_CLASS_MEMBER里面的内容类型一定要C++的基本类型？这样对所有基本类型都进行特化？