发现1：当开启DEBUG_LOG_GL_CALLS的时候，会判断所有原本运行正常的glDrawArrays出现数组越界的异常，修改了几下，发现开启log calls后，会多读1个点的数据，也就是最后一个参数的count+1，所以原本正常长度的顶点数组会被访问越界，不晓得为何会这样。
发现2：在真机上使用vbo的时候，如果开了debug，会导致在调用vbo相关gl函数的时候出现unsupported操作异常，可实际vbo功能却执行的好好的，同样不晓得为何会这样。
OpenGL ES
测试 Android G2 是否支持 OpenGL 硬件加速
参考此文：测试 Android G1 是否支持 OpenGL 硬件加速，对htc magic G2作出同样测试，记录结果，以供日后参考：
04-22 21:03:47.485: DEBUG/GL(2118): GL_RENDERER = Q3Dimension MSM7500 01.02.08 0 4.0.0
04-22 21:03:47.495: DEBUG/GL(2118): GL_VENDOR = QUALCOMM, Inc.
04-22 21:03:47.495: DEBUG/GL(2118): GL_VERSION = OpenGL ES 1.0-CM
04-22 21:03:47.495: INFO/GL(2118): GL_EXTENSIONS = GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_vertex_buffer_object GL_ATI_extended_texture_coordinate_data_formats GL_ATI_imageon_misc GL_ATI_texture_compression_atitc GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_stencil_wrap GL_OES_byte_coordinates GL_OES_compressed_paletted_texture GL_OES_draw_texture GL_OES_fixed_point GL_OES_matrix_palette GL_OES_point_size_array GL_OES_point_sprite GL_OES_read_format GL_OES_single_precision GL_OES_vertex_buffer_object GL_QUALCOMM_vertex_buffer_object GL_QUALCOMM_direct_texture
Android平台中BitmapFactory.decodeResource对GL程序材质的影响
在Android平台下实现OpenGL ES程序的贴图加载操作一般是通过BitmapFactory.decodeResource这个api，然后用系统封装好的GLUtils.texImage2D函数直接转换为gl贴图即可，方便快捷。但在较新版的Android系统中res中的图片文件夹根据dpi设备分辨率的不同，细分了很多文件夹处理以支持不同设备的分辨率加载对应的图片，如drawable-hdpi，drawable-ldpi，drawable-mdpi等，如果没有注意这个问题而将贴图图片随意安置的话，在decode的时候系统会默认根据设备dpi的不同对目标图片格式解码的同时进行大小调整，也就是说有可能破坏原本已经是2^n大小的贴图图片，导致原本在模拟器上正确的绘图在真机上变成大白板！
解决这个问题的方法可以将图片放到不受dpi影响的drawable-nodpi中，或者设置BitmapFactory的选项，不处理dpi相关问题。
windows mobile 6环境下的OpenGL ES开发环境设置
Mobile SDK用的是6 refresh附带6.5 chs的rom，IDE用的是VS 2008。
由于google到的相关gles和mobile的开发教程大部分都是对比较早版本的mobile sdk写的，所以可能到了6.0这个时代发生了一些变化导致教程上的某些方法不再适用了（至少我按着其中的做法没有成功…）。这里把能在模拟器上成功运行gles程序的环境设置方法总结一下。