opengl备忘
以前用d3d比较多,最近的一个项目采用我不熟悉的opengl做渲染api,碰到一些问题,这里记一下
- opengl采用列向量,所以相对于行向量的系统来说矩阵看起来是转置的
- 相应地,opengl矩阵是右乘的,也就是说右边的矩阵变换比左边的优先
- 依次调用glTranslate或glRotate等函数时,记住后调用的变换是先进性的
- opengl默认采用右手系,z轴朝向屏幕外
- glOrtho的near和far参数是其真实含义的负值!
- 也就是说例如你给的near=-100, far=200,那么实际上你能在视口看到的z值范围是(-200,100)
- 这个问题很隐蔽,花了我们很多时间才搞明白
新年快乐
刚才习惯性地上水木瞅了一眼,看见十大里有一个标题是“大家跨年做了什么”,才意识到已经是2010年了。
可以很骄傲的说,我是在写代码中度过的,好像去年也是……
祝福订阅这个blog的读者,偶尔来看看的读者,以及google到spam回帖中可疑关键词不小心点过来的过客
Grandpa SDK 0.51发布
What’s new:
- 提供max8和max9两个导出插件(原来只支持max9)
- 修正了模型包围盒没有更新的bug
- IModel::playAnimation现在返回IAnimation*(原来返回void)
Stack2另类过关集锦
上次推荐过一个flash游戏Stack2。这个游戏的过关条件是,用关卡提供的所有积木摆成任意造型,只要保持若干秒不坍塌即可。
玩的过程中你会感觉到每关都有一种游戏设计者“推荐”的摆法,往往从关卡名称中可以得到提示。但是好游戏的一个重要标志就是你可以充分挖掘想象力,用另类的方式来过关。
以下是一些另类摆放方式的截图。如果你碰巧也玩了这个游戏,可以交流一下:)
AI game player

刚刚从水木上得知一个星际争霸AI挑战赛的消息,久违的竞争欲望又开始弥漫……实际上我早就觉得应该有人举办这样的比赛了。想起两年前在老blog上发过的一篇文章,现在转过来:
本文说的不是“游戏里的AI”,而是“用AI来玩游戏”
曾经有一段时间对人工智能,尤其是博弈类的人工智能非常痴迷,大概是“深蓝II”打败卡斯帕罗夫的时候吧,写了一个五子棋程序,棋力很差,因为当时思路有问题,只用了一层搜索,大部分的时间都耗费在局面估价函数上了。结果是唬一唬五子棋初学者还行,下过我自己基本没戏,更不用说打败全人类了J。其实五子棋是状态空间很小的一个博弈游戏,很容易搜索到相当的深度,甚至某些开局已经被证明是必胜或必败而在正式比赛中被禁用,这也是阻碍它成为一个大的竞技项目的原因吧,相信现在最好的五子棋程序应该能轻松击败人类了。
Google C++代码风格指南
很多软件公司都会维护一份“代码编写指南”文档,规定(或至少建议)了代码风格范畴内的事项例如命名规范;缩进/空格/空行格式;对错误/异常的处理;某些语言特性的禁止或限制使用等。目的无非是希望代码更容易阅读和维护,更不容易出错,编译更快。
粗略读了一遍,绝大部分都深得我心(或至少可以接受),但也有一些我个人持保留意见的:
- 每行限制80个字符。这个限制的初衷是让读代码的人不用去拖动横向滚动条,但是以现在的显示器尺寸,80个字符也太少了……我个人一般遵守100~120的限制。
- 用空格而不用tab来缩进。是为了不管在什么编辑器里都是一样的缩进距离吗(一般编辑器都可以设置tab的大小)?,我觉得用tab挺好的,至少要删除缩进的时候方便很多。可能我vc用太多了。
- 把左边花括弧放在行末而不是单独占一行。这个我非常不喜欢,因为这样我总是看不清代码段是从哪里开始的。当然,为了节省一行以便屏幕上能显示更多行的理由是站得住脚的,但我更愿意将编辑器字号减小来达到同样的效果。在visual studio里貌似有些语言(例如JavaScript)居然还会自动把代码修改成这种格式,简直要把我气死。
当然,关于代码风格的问题多数是个人习惯的不同,每个人都希望别人把代码写成自己想看到的样子,但实际上要真正在哪怕只有3个人的团队中“统一风格”也很难。我在十几年的coding生涯中也经常因为环境而改变自己的编码风格,其实这些都是次要的,写代码的本质还是逻辑。要想让代码容易阅读和维护,本质上还是要让其中的逻辑更加简单。
DXT++纹理压缩格式
本文来源于Colt McAnlis在09GDC上名为Texturing Massive Terrain的演讲稿,可以在这个页面上找到ppt下载。我只是把原文提到的算法翻译整理了一下,DXT++这个名称以及下面所有插图都来自原文。
DXT++和DXT是什么关系呢?先了解一下什么是DXT。
DXT是现在绝大多数显卡都支持的一种纹理压缩格式,根据是否带有alpha以及具体的压缩算法等因素分为DXT1~DXT5几种格式,它们的具体差别请自行阅读相关资料,也可以参考云风的这篇文章。
DXT压缩的基本概念,以不带alpha的DXT1为例,是把纹理分成若干4×4像素的block,对于每个block记录16个像素颜色中的“最大值”和“最小值”(把颜色值当成一个整型来比较),然后每个像素用2bit数据在最大最小值间进行线性插值,也就是说4×4的区域内只会出现4种颜色。这样一来两个最大最小颜色占32bit(采用r5g6b5),加上16个像素每个2bit一共用64bit来表示4×4区域,平均是4bpp(bit per pixel),相对于原始的24bpp来说获得了1:6的压缩比。



















