在gl.h中定义了各个错误的含义：
看下就知道了。

cocos2dx是个2d游戏引擎，
但是是完全基于opengl渲染的，跨平台，所以搞手机3d游戏，用它来改造下，也不错；
他的2d部分退化为ui层，加多一个3d层就是了；
3d层处理好场景管理，对象排序，提交渲染，就可以了；
简单的游戏可以这么用，复杂游戏呢，呵呵。

with cocos2dx,to make a 3d game,yes,use cocos2dx to create 3d game.  C标准表示char类型可以带符号也可以不带符号，由具体的编译器、处理器或由它们两者共同决定到底char是带符号合适还是不带符号合适。
大部分体系结构上，char默认是带符号的，它可以自-128到127之间取值。而也有一些例外，比如ARM体系结构上，char就是不带符号的，它的取值范围是0～255
举例来说，在默认char不带符号，下面的代码实际会把255而不是-1赋予i：
char i = -1;
而另一种机器上，默认char带符号，就会确切地把-1赋予i。如果程序员本意是把－1保存在i中，那么前面的代码就该修改成：
signed char i = -1;
    另外，如果程序员确实希望存储255，那么代码应该如下：

       unsigned char = 255;

   如果你在自己的代码中使用了char类型，那么你要保证在带符号和不带符号的情况下代码都没问题。如果你能明确要用的是哪一个，那么就直接声明它。

The following email fragment appeared on the linux-arm mailing list recently:

	> consider this simple program:
	> int main(void)
	> {
	>     char i = -1;
	>     printf("%d\n", i);
	>     return 0;
	> }
	>
	> The print out is 255 in stead of -1, unless I define i as
	> signed char i;
	> then I get the "-1" print out.

The above code is actually buggy in that it assumes that the type "char" is equivalent to "signed char". The C standards do say that "char" may either be a "signed char" or "unsigned char" and it is up to the compilers implementation or the platform which is followed.

As the poster points out, the above code does not work as expected if "char" is "unsigned". It is difficult to detect this code at compile time, since GCC does not issue any warnings. The only way to detect it is either by visual examination of the code, or by actually running it and finding a problem.

This causes problems on ARM based machines since "char" is of the "unsigned" variety, which allows the compiler to generate faster, more efficient code. ARM is not alone in this - SGI Mips running IRIX also encounters this problem.

However, dispite the lack of warning for the above case, GCC does warn with the following code:

        {
                char foo;

                foo = bar();

                if (foo == -1) {
                        ...
                }
        }

Code like the above will generate a compiler warning, which will be one of the following depending on the actual test used:

	warning: comparison is always 0 due to limited range of data type
	warning: comparison is always 1 due to limited range of data type

Please note however that the above warnings are not issued if "char" is "signed" and therefore can be difficult to pick up when compiling in such an environment.

The following table lists the four types of code which cause problems when "c" is declared as just "char", and the most likely correct method of fixing the code.

先有
autobj =  a.o b.o c.o
all_dir =src src/common src/core src/engine
SRC_DIR =src/
OBJ_DIR=obj/
然后有：
$(foreach file,$(autobj:.o=.cpp),$(foreach dir,$(all_dir),$(subst $(SRC_DIR),$(OBJ_DIR),$(firstword $(subst .cpp,.o,$(wildcard $(SRC_DIR)$(dir)/$(file)))))))

解释：
1：foreach file,$(autobj:.o=.cpp)这半句的意思是，从上面autobj里头取每一个.o文件，将后缀改成.c;
2:$(foreach dir,$(all_dir),$(subst $(SRC_DIR),$(OBJ_DIR)这半句意思是，从all_dir把路径取出来，将字符串替换，src/将替换成obj/
3:$(firstword $(subst .cpp,.o,$(wildcard $(SRC_DIR)$(dir)/$(file))))))) 这半句是利用wildcard从目录下提取这个.cpp文件，如果有就返回.cpp文件带目录的文件名，如果没有就返回空，然后再将返回的文件名.cpp替换成.o，然后再提供这个这个字符串的第一个字给上一层替换；

最后，这个整个效果是，给定一堆.o文件名，给定一堆的目录，如果在某个目录下具有该.o对应的.cpp文件，则返回这个点.cpp文件的长路径名，这样就可以自动搜索目录，写makefile就去掉了一些繁琐，对于大工程复杂目录，方便很多
                 

在arm处理器上，运行程序会遇到Datatype misalignment问题而crash，而同一代码在x86 win32环境上编译后运行良好；
其实不管是x86还是arm都会遇到Datatype misalignment问题，比如d3dx用到sse指令优化的D3DXMATRIX时，需要这个变量16字节对齐，否则可能会crash。
同一问题在arm上会更明显，因为arm的硬件处理可能没有pc机cpu这么强悍，针对arm的编译器可能也没这么强悍，这就需要我们写代码时候更健壮，考虑更多；
比如下面的代码就比较糟糕：
char buf[71];
int* pItem=&buf[11];
很有可能刚好，这个pItem的地址为奇数，或者不是4的倍数（32位系统），这样就遇到了 Datatype misalignment 问题，好的办法是，不要瞎转指针，需要是用union，这样编译器就能生成比较靠谱的代码

check this
老外的详细解释：
http://blogs.msdn.com/grantri/archive/2004/07/14/183524.aspx



//另外在vc种设置“结构成员对齐”，如果不改动，是默认值，就是8bytes对齐，
/Zp（结构成员对齐）
当指定此选项时，第一个结构成员后的每个结构成员将存储在成员类型大小或 n 字节边界（其中 n 为 1、2、4、8 或 16）两者中较小的一个边界上。
也就是说，如果是指定16bytes对齐，实际代码是如果遇到一个成员是int，其实这个成员对齐是4的倍数的地址，就可以了。。。。不是16，呵呵；
答案是，完全不需要；
请见
http://www.cnblogs.com/wswqwps/archive/2008/10/25/1319346.html

http://www.gamedev.net/community/forums/topic.asp?topic_id=428738

看看这俩帖子，基本就清楚了。

但问题是：
我的老显卡ati9700不支持 “渲染到浮点纹理，同时需要alpha测试”，但如果在shader中写上clip（color.a>20),也能实现alpha test，但帧数明显低很多，唉怎么办

开源3d软引擎下载http://muli3d.sourceforge.net/index.php

http://muli3d.sourceforge.net/index.php

所有向量运算都用过软件计算，接口采用模仿d3d的接口方法，矩阵运算，投影变换，之类全部都有源代码，下来学习参考非常合适。

并且支持shader，当然也是软件实现，，，，

如果哪位大侠开发3d硬件，用这软引擎开发相关模拟器，或者试验相关算法是否正确，实在非常合适。。。。
比如当你用VHDL 写3d场景中常见的矩阵处理算法，在fpga上测试发现结果老是不对，那么如果你基于上面的开源引擎（或者经过大规模修改），用同样的算法，用c++写一个软算法，在windows上一跑，交叉测试，效率倍增。。。


---突然想了很久，想不起这个引擎的名字，最后还是在一个网站曾经自己发的贴子上找到了，哈哈，再贴这里，免得再次遗忘。。。。
d3dx矩阵旋转
1:绕x轴旋转，y轴正向为0度，延x轴看向原点，顺时针旋转角度增加;
2:绕y轴旋转，x轴正向为0度，延y轴看向原点，顺时针旋转角度增加,也就是，vec[1,0,0],这样转30度后，变成vec[0.866,0,0.5];
3:绕z轴旋转，x轴正向为0度，延z轴看向原点，顺时针旋转角度增加,也就是，vec[1,0,0],这样转30度后，变成vec[0.866,0.5,0];
以上结论，都是傻子做法，用下面几个例子看出来的：
D3DXMATRIXA16 matRot0,matRot1,matRot2;
D3DXMatrixRotationX(&matRot0,D3DX_PI/6.0f);
D3DXMatrixRotationY(&matRot1,D3DX_PI/6.0f);
D3DXMatrixRotationZ(&matRot2,D3DX_PI/6.0f);

//下面链接是讲这个旋转的，不过它的矩阵是row－major矩阵，所以他说RxRyRz,performs the roll first, then the pitch, and finally the yaw,而我们用d3dx，是column-major
http://planning.cs.uiuc.edu/node102.html

注意一点，旋转是三个方向的结合,roll,pitch,yaw,其先后顺序不一样，结论完全不一样，没有对错之分，只看你应用的需要，一般游戏中操作相机时roll很少，只是yaw，pitch，而且通常，只有一个成分在作用。。。。