坤·十年之前

不容易啊, 先是没了免费无线, 接着用同屋的长宽, 果然烂得没话说, BT, eMule连不上, 游戏pin只有大半夜两点到早上9九点才稳定, 前两天还没法上开心网, 恒等于没网上.

跟成都电信的对比一下. 因为总共只办过三次宽带, 采样肯定是非常少了, 也没什么代表性, 只是觉得呢这边很久没写了, 来凑凑字数....

成都电信第一次是通过10000申请的, 没经过区域经理, 技术人员上门签协议收款, 安装的时候蛮专业, 进门穿了鞋套, 主动给我看工作证, 等等. 基本上算是满意, 没有太多可说的.

第二次是联系的区域经理, 小区优惠80块钱1M, 包半年免电话和宽带初装费, 不过电话座机费倒是照常交. 区域经理上门签协议收款, 但是过了好几天都没来装, 联系经理后被告知技术人员电话, 打过去问了才说单子上没我电话, 联系不上....后来上门的时候很随便, 大概因为那一带都是学生租户, 所以也没把大家当成普通用户看待吧. 给我看了单子, 果然那单子有一半都没打出来, 自然看不到我电话号码....当时就觉得奇怪了怎么他们打单子的时候不看一眼, 然后重新打的么?...

这次就是武汉区域经理了, 感觉协议的签订没有成都那么正规. 成都会签订电信专门的协议, 并且使用电信专用发票, 这边收款的时候就给了我个普通的盖了电信章的收条, 协议也没有给我. 然后, 区域经理的整个风格非常的粗犷, 呃....相比成都那位西装革履的经理来说确实是太过随和了些....技术人员今天上门的, 态度还不错, 其实也没太多说的了, 设置什么的我也搞得定.

最后说下, 无线真好用....

为了统一操作, 在设计初期就确定了, 除非函数没有相应的gl*****d()版本, 基本的数据类型都统一为GLdouble.

有几个数据对象是必须要用来支持OpenGL操作的: 坐标Coord, 颜色Color, 顶点Vertex等等. 本来也有考虑向量Vector的实现, 但是向量的操作稍微复杂了一些, 并且暂时也用不上, 还是考虑以后再慢慢加上. 其中对于Vertex的设计是直接多重继承自Coord和Color, 这对于一些高级顶点对象(例如, 定点还包含了法向量)来说是不够的, 不过一般使用倒是够了. 当然也可以采用组合的方式, 不过派生类接口就需要重写. 另一方面, 因为是经常用到的简单基础类对象, 所以方法的实现基本上都是采用了inline的方式: 直接在类声明体中进行方法的实现.

在最初的设计中, 这些基本数据对象都是独立实现的, 并没有基本父类, 而数据成员则是使用的数组. 使用数组的好处就是可以调用gl*****dv()从而减少传值调用的开销. 后来考虑到"对象"的直观性, 将数组更改为了单个的成员, 例如Coord中就为_x, _y和_z.数据成员为public性质, 可以直接访问, 当然也有相应的成员函数进行设置. 这样一来在处理和使用时就更直观.

后来重新熟悉了OpenGL的一些基本概念之后, 感觉使用glDrawElements()能更加有效的节省处理时间, 于是又对这一块进行重新设计. 不过因为接下来的时间都用在准备搬家上了, 基本上, 就卡在了这个地方. 现在的设计思路是增加一个基类: DataManipulator, 用于对数据操作进行抽象. DataManipulator的数据成员_data为一个指针(而不是数组), 并且有两种对数据的操作方式: 当_own_data为true时, _data指向一块new的内存空间, 并需要在析构函数中进行delete; 当_own_data为false时, _data指向一块由外部对象维护的内存, 可以对此内存块进行操作, 但是不拥有delete的功能. 将两种操作方式融进一个基类, 其实对于实现来说是增加了比较多的复杂度, 但是带来的是使用上的灵活性的提升.

当然, 一切都在设计阶段, 也许后期又会进行设计策略上的更改.

最初的设计是将整个显示环境分为三个区域(Section): 背景区BackGround, 内容区Content和前景区Foreground. 其中内容区默认将深度检测打开, 用于显示三维内容; 而前景区则将深度检测关闭, 用于显示UI信息. 背景区因为觉得其实可以归结到内容区的(或者直接使用环境光设置背景即可), 因此省略掉.

内容区的绘制由具体的应用决定, 框架中只要求提供非常基本的几个需要实现的接口, 如Display(), TakeAction()等等. 内容区最初也是设计为"层(Layer)"结构的, 但是后来考虑到层的概念与三维空间还是有所区别, 因此也取消这一设计.

而前景区则确实借用了"层"的概念. 前景区由一系列的"薄片(Flake)"组成. Flake是平行于XY坐标的, 并且默认不具备旋转和缩放功能(否则在实现字体显示时会很麻烦). Flake的层叠顺序决定了它的显示顺序: 由于关闭了深度测试, 因此最底下的Flake将会被最先绘制. 直观来说, 这样的绘制策略就跟Windows的窗口绘制差不多, 当然从实现机制上来说要更简单些. 毕竟EflaKer的目的还是做一个相对简单, 具备基本功能的Framework, 而不是一个Windows Vista模拟器.

当然目前的计划是, 对于Flake中基本控件的外观绘制, 会多少参考一些Vista的设计(玻璃特效? 唔, 其实我也不是很清楚, 大致就是类似MSN8.5那种的吧, 使用一个基本颜色的不同色深来对各个Component进行绘制).

因为搬家的事, 同时又刚买了本本, 仿佛回到了以前忙着工作的时候, 白天不知道忙的是什么, 晚上就只想安静的玩玩游戏, 程序是一点没心情写了, EflaKer的开发进度也因此停了下来.

今天回过头来看, 居然不知道该从哪个位置继续入手了. 唉, 没办法, 之前做得急了点, 老想着快些把基本的框架和功能实现出来, 文档和注释就给落下了. 不过写了也麻烦, 因为现在的设计改动可能会很大, 毕竟是没做过的未知的东西, 写了文档以后要改的东西可就更多了. 但是其实EflaKer的雏形现在是有了, 就是太简单, 还是算了, 暂时不要发release.

这几天要把心收收, 继续把东西给做出来.

今天试了一下, 这边的IP居然能访问SourceForge. 又或者本来就是禁令已经解除了呢? 嗯, 不得而知, 不过对于我来说, 倒算是个喜忧参半的消息. 本地代码管理还是坚持用了Perforce, SourceForge那边又是有CVS帐号和服务器的, 不知道是不是必须把代码提交过去呢? 不想看鸟语说明文档啊, 不管了....

之前还打算过慢慢复习一遍, 无奈全英文加上懒惰的情绪, 实在没法坚持下去.最近几天开始准备卖书了(虽然存书不多), 想着还是过一遍吧, 于是就胡乱过了一遍.

怎么说好呢, 因为主要都是讲述算法和图形学概念, 老实说虽然是厚厚的一大本书, 能涉及到的东西实在非常有限. 不过很多东西也就只有用到的时候再去看了, 毕竟工程性质的知识, 丢久了不碰也就真的丢了. 好像也没有总结的必要, 大致就是复习了下模型视图变换那部分的东西, 算是捡了一点点回来. 当然, 那些矩阵要让我写是背不出来的了. 于是只好自我安慰一下道: 这些东西, 图形系统里都有封装好的接口, 不用了解得太具体.... -_-!