hhai

@SIXWATER
还好还好,挺安稳的,六水兄还在上海?

@ZealKing
请认真看文章

最重要的———工具呢？有没有完善的document和sample？另外只有渲染没有逻辑，网络方面的支持？

@丁小饼
现在已经找不到了，不好意思，你可以从这里http://www.punkuser.net/vsm 下载vsm的demo

@yezi
请不吝指教,详细点,谢谢

恩...粒子的更新我还一直想放到GPU上去计算,放到脚本里恐怕粒子数量稍大就歇菜了,特别对于复杂的效果.

@溪流
遇到这种情况,难道你不是在GetInstance函数里检测被修改的时机吗.....?

。。蛋定，要蛋定

OGRE使用的是列主矩阵,简单说就是左乘列向量,而你在HLSL中的写法是行向量左乘矩阵,自然需要转置

@Tangel
http://muli3d.sourceforge.net/
http://users.softlab.ntua.gr/~ttsiod/renderer.html

@Mars2020
这篇文章是我很早之前写的了，细节我也已记不清，你上面给的代码我没看出什么问题，不过为什么你把所有顶点weight都设为1呢？一般来说，骨骼动画模型会散掉就是因为顶点权重或者骨骼矩阵不对

人要能一辈子这么单纯也不错，只可惜压力逼着我们改变

@G++
对渲染队列进行排序，由前向后渲染物体，这是一种基本的优化策略，至于透明物体的排序跟这里的排序解决的不是一个问题，方式也不一样

你有对渲染列表进行排序吗？个人理解，你的第一个问题就是像素填充率导致的，然后第二个问题，不知道你是不是用D3D进行渲染的？D3D默认的z测试方法是当当前像素的Z深度小于或者等于深度缓冲的值时通过测试，你把所有骨骼动画模型都渲染在同一个位置，在默认情况下每个像素都会通过测试进入你的ps程序中进行处理，这样就加重了渲染负担。

呵呵，学生时候的俱乐部社团什么的玩玩就好，犯不着为它闹心

@陈梓瀚(vczh)
2,3有在考虑

@支持
还没有具体的思路

如果LZ的项目是自己玩玩的那当我没说

@陈梓瀚(vczh)
商业项目每一分钟都在花钱，以学东西的态度来做这个项目的想法是会气死老板的

那个..假如你采用后一种方案的话，那么光是做这个游戏引擎估计就能耗上你们一年左右的时间，而且用OGRE来做3D动作类游戏也是不太适合的，当然我不知道你们团队的规模和能力

手把手啥啥啥。。。好吸引的名字

@cppexplore
接受你的鉴定同时进行深刻的自我反省

@陈梓瀚(vczh)
是的,其实对效率的追求源自本人的偏好,有人说是偏执

@陈梓瀚(vczh)
good idea

@陈梓瀚(vczh)
是个办法，不过这样做如果a中并不存在doSomething的话就没办法在编译期就抛给用户一个错误了，而且在运行时查找，效率上恐怕也是个问题

@陈梓瀚(vczh)
可否说得详细点？

@陈梓瀚(vczh)
指令集直接抄的XX语言的

@yindf
自己定义"汇编"是挺好玩的

RetVal作为一个虚拟寄存器

可以这么理解

大小在定义的时候就确定了

刚弄出一个可运行的玩意,很多东西都还没具体考虑

@陈梓瀚(vczh)
是挺有性格的,呵呵

＠Touchsoft
这是DEBUG版本,目前引擎的效率的确还存在问题,但单是粒子的话在ＤＥＭＯ模式下Release版１Ｗ个粒子也有７０帧左右

厉害啊~~~~

楼主能否把完整代码发送到chenweizi@sina.com
多谢