re: 开始重构 李侃 2009-12-10 08:51
6个月太短了，我搞了三年半了，完全靠自学进步同样缓慢，很多地方也还很欠缺，就是有计划的去修炼提高，欲速则不达
就是个细致活，多画画图，找找规律，自然就能发现其中的拓扑结构了，就是用程序生成索引，然后缓存索引，别无它法，完全避免重复无谓的lock,unlock
当然是用程序来生成索引了，我现在已经改用17x17的规格了,33x33有点大了
re: 开始重构 李侃 2009-11-14 20:21
这个很容易的，只要做好地形编辑器，让地形刷子能精确控制边界的贴图过渡的问题,刚好这部分最近正好在重构，混合部分我打算采用改进的“非线性”混合，能大大提高混合精度，待重构完成，其具体做法，我不久之后会发布到博客上，敬请留意
re: 渲染方面加了一个bloom效果 李侃 2009-09-16 12:50
其实看看那些艺术照和生活照的区别，就是晕光蒙蒙的效果，对比也显得强烈，看少了还不错，看多了，就不爽了，感觉不真实
有的人会说，如果不是艺术照下的MM都很迷人就是极品了。
扯的有点远了 : )
不会啊，我用着没问题，很久没搞过newton了，早改physx了
不过physx的例子也用的GL，跟渲染引擎没关系，你只要关心物理方面的结构就行了，看东最开始的例子，然后凭理解在dx里面写，都差不多
MFC都用习惯了，是陈旧了点，不知道为什么没有后续支持来升级UI库，可能这就是真正挨骂的原因吧，
WxWidget 好像也是很庞大的哦，里面的例子很多，确实很吸引人
re: A* （路径搜索）算法导引 李侃 2009-08-15 17:27
这片文章很老了，但确实是好文章，过去就是看了该文来写A*的。
同意2楼，共享资源传统的方式最好使用共享锁和排他锁，分而治之，可以参考读写锁的实现方法win32下单进程内建议使用用户模式，interlock系列函数足以
锁无关数据结构我还没找到很好的解决方案
re: 浅谈状态机FSM设计方法 李侃 2009-08-08 09:43
全部是网上找的资料，GEM系列书上有介绍过，资料很零碎，具体上面的状态机封装形式还要结合脚本引擎，才能真正发挥它的威力，我已经这么做了，总之，就是一句话：很好很强大 o(∩_∩)o...
我用的是directx，模型采用自己的格式用的是shader和固定管线两个版本都支持
re: 新加入了PSSM全场景阴影 李侃 2009-06-18 18:02
囧...
我明白，如果是vector<Entity*>的方式，根本不用去讨论该去用vector还是queue，重排就重排了，指针不会变
但如果是vector<Entity> 的形式情况就不同了
这样的类别的集合确实就不该直接去引用集合中元素的地址，这不是一个好的习惯。
主要是：我的序列化存储层只能支持 集合<entity>的形式
不支持 集合<Entity*>的形式，想引用从文件读取的集合数据又不想做太多的拷贝，迫于无赖。
只好回头再想想看有没有更好的折中方案了。
后面的部分是我摘录网上的文章，觉得好像也没什么不妥
当然了如果元素被移除了，这样去访问那会是危险的。
我试了试，似乎erase中间的元素以后，各元素的地址依然稳定，vc自带的的deque 是这样的，不知道其他版本的deque会不会也是这样？
我已经深深的爱上deque了 ^^
我现在讨论的不是迭代，任何集合都能迭代，光用一个iterator去遍历，任何集合都没有差别了。那一个vector就够了还要list和deque做什么？
我现在讨论的是它们的内部结构的差别，根据不同的场景而要用出这些集合的差别才是真道理，楼上看清楚，我现在就是想在外部指针去引用集合内部的元素，就是不想每次访问的时候都去迭代，集合如果只增不减的情况下，用deque是稳定的,而vector是不稳定的，vector存在空间重排，deque不存在空间重排，这是我要阐述的观点
re: 游戏资源在线更新的思路 李侃 2009-05-09 22:42
那DLL里面的版本号呢？功能模块的DLL都是编译器生成的，你要在每个DLL里面再附加资源信息吗？我觉得有点繁琐了。何况如果每个文件都去解析里面的版本号的数据，速度是会很慢的，不仅繁琐，而且更难控制。
不过一些版本控制软件的却是加了版本号的，但也是有版本索引文件去记录这些版本，但绝对没有要求一定要在源文件中去加版本号。所以时间要素控制版本是高效便宜的做法
re: OO中对于23种设计模式的整理 李侃 2009-04-23 16:00
/2/3 /
/1/ ?/
?号的部分的级别显然应该是2，观测点因该在1点半的方位，前面叙述过，而且实践检验过，通过设定好的阀值，相邻的block级别不可能相差超过1的
各种级别和边的补缝形态索引的确是要计算的，但用过了不要浪费，我定义了一个cache，四条边的补缝形态以及除了四条边以外中间的形态都放入了缓存，缓存找不到的时候就计算，然后加入缓存，最终缓存能把所有形态填充到缓存，就不再需要计算lod形态了，我采用的就是这样的算法，能很有效的避免lock unlock，另外这点内存上的开销在空间上几乎是一次性的开销，其实非常的小，不必在意的。
lod影响的因素如果考虑起伏分布，的确是个高级话题，暂且还没考虑这些要求，但如果做个地理信息系统的时候，确实就很有必要了。
过年回家上次网不容易
lod级别我用的是最简单的 观测点到block中心距离×阀值(一个小数) 来确定的，相当于运用一个策略钳制一个LOD当量在可用级别范围内，传统的方式都是这样做的，当然要做的更复杂，不能光靠距离来决定lod级别，比如起伏大的地形用高的级别，平坦的地域用低的级别，这可以说是另一个高级话题了
这帖子快一年了，回头看看，还真是感触颇多啊
后来我还是自己写了一套序列化的库，完全支持stl + zlib字节压缩的的序列化库，最终还是没有采用结构体的方式
自己写的这套库工作了很久了，也是我的IO和网络流的底层，用起来还是很方便的，足够了
3dMax里面一组面可以成为一个mesh，每个房间的面是一组mesh，是手工拆分好的，没有按照自动拆分portal的方式来做，那样太变态了，还是手工来的准确和灵活
偶现在用physx了，很久没用过newton了，physx那里面的矩阵和dx的到是不一样
跟VS里面的停靠窗口一样的效果啊,悬浮状态调整大小不影响渲染窗口大小,铆钉铆上以后调整大小影响全屏的渲染窗口大小
re: 服务器端无限大地图的构想 李侃 2008-11-27 16:09
我的无限大是指：想要多大就多大，也就是说无论多大就可以。
我已经实现了从一头走到另一头走1天也走不到头的地形，无论多大运行速度都不受影响，场景所有数据全部实时动态加载和释放，而且已经研发了配套的地图编辑器，全部采用可视化编辑的支持
目前地形编辑器已经很好的支持室外场景编辑
室内场景也整合到了地形上，正在完善
所有的已经全部按计划实现了，目前在做符合游戏引擎要求的进一步完善
比如AI所需要的数据设置等等一些东西，地貌的渲染部分是下一个阶段的目标
另外：我只搞3D
俺用模版库写了一个支持STL容器的Serializer ，内部可选择用zip压缩字节，以及加密解密字节，已经用了很久了，感觉很爽
每个tile是独立的blendmap，而且我用了两层，其实完全可以考虑只用一层，就混6张，每个通道0－127 一个图128-255一个图， 127的色阶基本也够用，以前见有人这么搞过，后来想想也没必要节约这点资源了。
boost是很好，可有些庞大，目前并不打算使用
我已经加入了fastdelegate，这个短小精悍，足以解决我的问题了。
不算太复杂，SDK里面很多文档和例子可以参考，我目前只简单弄了弄静态模型的导出，动画方面的模型导出还没做深入的研究，另外导出格式自定义的流格式，对串化需要做深入的研究，否则只有xml了
我还是使用了以前的方案，没有放在OnIdle里面
这个函数在优先级别太低了。
原先看了游戏精粹2介绍的就是这样的索引形势，没什么诡异的啊？
初识A*算法
f(n) = g(n) + h(n)
其中f(n)是节点n的估价函数，g(n)实在状态空间中从初始节点到n节点的实际代价，h(n)是从n到目标节点最佳路径的估计代价。在这里主要是h(n)体现了搜索的启发信息，因为g(n)是已知的。如果说详细点，g(n)代表了搜索的广度的优先趋势。但是当h(n)>>g(n)时，可以省略g(n),而提高效率。
主要是看了这段介绍
是啊，H做了判定，G没有考虑，需要改进一下评估函数
我现在决定选择luaplus和C++连接了，那样方便很多
否则全手工调用那些栈真的很烦
re: 使用LUA 李侃 2008-06-18 21:41
收下了，感谢你，邻居
刚下了physX，里面的布料效果很吸引人，没有物理显卡，跑的也还算流畅。
文档很齐全，看来是得认真考虑考虑了
给你看另外一个东西
http://www.cnbeta.com/articles/57171.htm
你觉得这个大家伙怎么样？够成熟吧
呵呵，这个我知道，只是觉得phyx太过商业化了，而且需要那个什么物理卡，真不知道没有那物理卡性能会怎么样？
GL现在已经不再是问题，我在试着用dx做第三个例子。
newton的物理引擎的api 函数真的很繁多，要想用好他们，不是那么容易的事情，还有一些物理知识也有些生疏，这样看来掌握好也不是一两天的事情了。
计划把sdk里面提供的12个例子全部看完先。
目前练习完前两个例子的感觉是，newton的封装很优雅，非常注意回调函数的使用，状态监听能够运用自如，大大增强了其灵活性，另外newton的文档也是比较规范的，每个案例都有配套的指南，是很好的教程
看来楼上是行家，一眼就识破了，的确用了两层纹理，一共8个通道，1个通道做光照，另外7个通道做混合，用的SM2.0，不过昨天加入了shadowmap支持的阴影，ps象素运算指令数超过了64，逼迫我用了SM3.0，郁闷，我今天准备来优化
所有的场景都是用我的用这个编辑器生成，和绘制的
那个黄色的圈就是笔刷，地形高低，纹理，光照都是刷子刷出来的，参照了OGRE的goof插件编辑方式 ，还有参考了photoshop的刷子，那个是刷平面，我是刷3d的场景呵呵，有点不同的感觉
模型是从编辑器拖放到场景中去的和3dmax感觉差不多，这就是个3d游戏的场景编辑器，是游戏引擎的一部分，完全自主独立开发，下午又发现了一些bug，正在改进之中...
昨天和你聊了聊，所获不小
搞了半天还算是邻居
以后多多交流啊