2003-1-12
2003年1月10日我在CSDN上同步发布了Looking开发日记，在这里我要感想CSDN的工作人员对我的支持，特别是ghj1976和熊节。在这里，我要对CSDN的工作人员的热情和极高的工作效率表示由衷的赞叹。同时，我要再次感谢VCHELP的版主闻怡洋给我个人专栏资格，并且修改了专栏发布体系，增加了图片发布功能。
Looking系统当前开发的焦点已经越来越向3D Engine本身靠拢。在调试完csg和bsp之后，Looking开发的当前任务是开发PVS(Potentially Visible Set)。在第一篇Looking开发日记中，我曾经说过：我要开发一个BSP＋PORTAL的3D引擎。但是，到目前为止，还没有任何关于Portal的开发。之所以会出现这种情况，是因为我对Portal有很多的困惑。Portal有很多非常明显的优势，但它也有一个非常明显的劣势：运行时刻polygon裁减。如何在BSP中利于Portal，我还没有清晰的概念。因此关于Portal的开发被放到以后研究后再进行。
到目前为止，Looking的开发还是没有把注意力集中在光照和材质上。我想，光照和材质是于polygon相关的，在polygon相关问题没有完全解决之前去考虑光照和材质问题会导致开发的重复，降低开发效率。另外，对于光源的放置和Solid中具体polygon的材质的确定，是Looking Editor的内容。当开发到这一步时，将要对Looking Editor和Component进行大规模的扩展，其代码量会非常大。我更希望在解决LJet中的一些最基本的问题后，再去关心这些问题。
在第一篇Looking开发日记中，曾经提到过Looking系统由Looking编辑器、Looking编译器和Looking解释器三个部分组成。但好像到现在为止，对Looking编译器和Looking解释器好像支字未提。这其实是一种错觉，Looking编译器和Looking解释器的核心就是LJet。而当前的开发焦点PVS就是Looking编译器和Looking解释器的核心中的核心之一。当Looking解释器在运行Looking文件时，会在内存中构造一棵BSP树，该树对world space进行进行二叉分割，而该树的每个leaf node是一个polygon的凸集。PVS就是分析这些leaf node之间的可见性关系。我对PVS没有什么特别的见解和新颖的算法，我只是要利于ray trace来实现它。
在进行PVS编程之前，要进行一些必要的辅助性编程。最紧迫的问题是实现Looking Editor的Serialization。难道说Looking Editor到现在还没有实现Serialization么？确实是这样，Looking系统应该说是一个不小的系统，而开发人员就只有我一个，我实在没有更多的时间来关注这些问题。但现在要开发PVS就必须要先解决Serialization问题，因为在相对简单的场景中PVS是没有意义的，也是无法调试的。要开发Serialization，我就面对着一个抉择：是每个Component自己实现各自的Serialization？还是有着一个统一的缺省的Serialization方式，每个Component只有在必要的时候重载该方式？我选择了后者。原因是后者所站的高度要比前者高一些，这样它就有了相当的涵盖面，而且他确实能够完成我所要完成的工作。这种方式的关键在于一个必要概念：Component在Looking Property Editor中所表现的属性足以初始化该Component。实际情况也确实如此。这样，Looking Editor关于Serialization的开发又回到了Looking的起点，也就是Looking开发日记第一篇的描述。既然，我们知道每个属性的名字、类型和值，我们当然可以对其进行某种形式的Serialization。那么下一个问题就是使用哪种Serialization方式，说的简单一点就是：使用BIN模式？还是ASCII模式？这着实让我矛盾了一阵。使用BIN模式，会使开发更容易一些，生成的文件更紧凑一些；但，它的扩展性不好，调试性不好。比如，当我调整了一些Component的属性后，旧的BIN模式保存的文件就有可能报废。而对于ASCII模式，我可以使用name＝value这样的name-value pair，当Component增加某些property后，在以前保存的文件中没有该property的描述的情况下，它可以使用其缺省值。我甚至可以干脆把ASCII模式的文件保存成XML文档。但是这必然要增加代码量。尽管是痛苦的，但我还是选择了ASCII模式，因为以后在进行copy/parse操作时，我甚至可以直接使用DF_TEXT剪贴板。明确了设计目标，剩下的就是coding、coding再coding。
PVS现在正处于开发调整过程中，我将会在下一篇Looking开发日记中详细描述。
在Looking日记中，已经提到过LJet很多次了，但是我发现关于LJet的很多基本问题我没有提到。
首先，LJet是用什么语言开发的？关于这一点，LJet显得很矛盾。基本上LJet是用C语言开发的。但它也使用了C++的很多特性，比如：重载和模板。之所以成了现在这个样子，有以下几个方面的原因：
1、LJet的设计目标是作为一个API的载体。OOP特性对于API来说，我感觉有些多余。
2、考虑到LJet的移植性，我没有敢使用OOP。对于Unix下的C编程，我比较熟悉，但Unix下OOP编程的说道我就不太了解了。
3、之所以要在LJet中使用一些C++特性，主要是从代码的语意上考虑的。对不同的对象完成相同的功能的情况下，我喜欢使用相同的函数名，这样比较便于我记忆。例如：判断一个vertex与plane的相对位置的函数和判断一个polygon与plane相对位置的函数，我更希望用相同的函数名。
J_API JPLANESIDE jPlaneDetermineSide ( PJPLANE pPlane, PJVECTOR pV );
J_API JPLANESIDE jPlaneDetermineSide ( PJPLANE pPlane, PJPOLYGON pPoly, PJVECTOR vertices );
4、从内存分配策略上来说，我也没有敢使用OOP。对于这一点，将在下面解释。
5、心情上的原因。说实在的，我对OOP有点厌倦了。我记不清我一年要创建多少个class，应该很多很多。我很怀念以前在大学里用C编程的那段时光。
总的来说LJet是使用C++编译器来进行C编程。
其次，LJet的内存分配策略是如何实现的？在这一点上LJet同样表现的矛盾而有趣。在LJet中，自始至终贯穿着内存池的概念。无论分配什么对象，LJet都要定位相应的内存池。在LJet中分配内存的函数描述如下：
void ×jAlloc( JDWORD size, PJMEMORY_POOL pool );
从该函数可以看到，在LJet中内存池的概念是无处不在的。使用memory pool的好处是显而易见的，它可以实现定制的内存分配、回收策略并且可以减少系统资源的利用和提高代码的移植性等等。对于内存管理的问题，在这里就不一一说明了，有兴趣的请参阅操作系统之类的书籍。memory pool的实现大致上都是分配一系列的chunk，然后再分配具体的对象。这样，我们就可以在系统开发的优化阶段，统计系统分配内存的特性，从而选择相对合适的分配策略。另外，这种分配方式可以极大的减少操作系统的内存碎片的产生。那么，LJet的内存分配策略到底是什么样子的哪？呵呵，其实LJet到现在为止，还没有什么内存分配策略。他只是提出一个memory pool的概念，而没有任何的实现。具体的实现，要在优化阶段来完成。看过Linux应用源代码的都会发现，很多系统都有类似jAlloc这样的内存分配函数，这些函数中基本上都要调用ANSI C的标准内存分配函数malloc。那么，LJet是如何实现的哪？LJet没有使用malloc，至少在系统优化实现memory pool之前，都不打算使用malloc。当前使用的是C++的new。这主要是要利用VC的内存泄漏检测机制。VC的内存泄漏检测机制实现的非常优秀，无论是inproc com还是普通的DLL中的内存泄漏它都可以检测出来。关于VC内存泄漏检测的具体内容，请参阅windows的heap管理相关内容。尽管，memory pool可以极大程度上减少内存泄漏的可能，但我更希望我的系统是完整的、强壮的。从内存分配的方式上可以感觉到，如果使用OOP会导致概念上的不连贯，尽管这种分配方式不会对C++的使用造成不便。
在对LJet的描述中，我多次说到移植性的问题。这并不表示我要开发一个Looking的Linux版，而是另有目的。如果有一天，用Looking进行真正的3D游戏设计，那么在Looking编译阶段会使用很长的编译时间。比如在生成bsp树的过程中，存在着world space最优分割算法的问题，该算法从复杂度分析的角度来看，要使用的cpu时间是非常巨大的。在这种情况下，使用分布式计算会大大提高编译效率。一个最简单的cluster，都会使编译时间成倍减少。要实现这样的功能，没有比linux更合适的了。因此，LJet必须是可移植的，而且Looking编译器也必须是可移植的，并且要考虑分布式计算问题。我之所以要有这些考虑，是来自于我以前读过的一本书“图形程序开发人员指南”。该书的作者就是Quake的主设计师之一Michael Abrash。他曾经对Quake编译Bsp树时的时间有过一段描述，具体内容记不清了，好像是一台8个CPU的服务器要运算一周。
当Looking开发日记在CSDN上发布时，很多读者对于我找不到工作而感到奇怪，在这里我要说明一下原因。这可能要产生一大段程序人生的问题，对于不喜欢Looking开发日记中程序人生部分的读者来说，这篇Looking开发日记已经结束了。
我在网上发表关于程序人生的文章是要说一些在实际生活中想说但又不敢说的话。如果，这些话导致某些人的反感，在这里我表示抱歉。
我在申请CSDN专栏作者的时候，提供的个人资料中，关于特长一项的描述是：程序设计、围棋。CSDN的专栏维护者ghj1976工作非常负责任，他发EMail给我说：程序设计说的太笼统，比如哪种语言，哪个方面。但我没办法回答他。呵呵，这是我在求职过程中遇到的一个非常大的难点。一方面，在我的个人知识体系中，我的特长可以说是无限扩展的。我可以非常轻易的学习某种语言或技术。举一个最近发生的例子，2002年3月，公司让我去开发网络管理系统。当时我对SNMP闻所未闻，毫无概念可言。但一个月后，我就已经在修改ucd-snmp的部分源代码了。呵呵，当时是因为我粗心，没有看到ucd-snmp关于MT支持的readme文档，于是自己试着修改ucd-snmp以增加多线程支持。至于具体的语言问题，相对来说就更简单了。2002年12月，公司让我参加一个开发EJB的项目组。以前看过两篇EJB的文章，但没有实际作过，更不要说什么WebSphere之类的东西了。但两天后，我就已经开始用WebSphere繁殖代码了。至于Looking本身的技术种类就更多了，其中大多数都是边看资料边写代码。但另一方面，我几乎没有任何特长可言。原因是我的记忆力出奇的差，我想这可能是因为我小的时候受过严重的脑外伤的原因，呵呵，可能海马体严重受损。每当我新认识一个同事，我会至少问他4遍你叫什么名字。我经常忘记自己家的电话号码，和自己的手机号码。对于开发语言和技术规范，我只能记住最近使用过的东西。从这个角度来说，我的应试能力可能是人类中最差的了。2001年末，我到北京某大公司进行了一次面试。去的时候不知道他们主要关心的语言是什么，而且我也没太在意。到了之后才知道是J2EE。在这之前2个月，我曾写过一个类似Java的脚本解释器，该解释器完全是参照Sun发布的Java语法规范编写的。在Looking开发的后期，将会使用该Script进行事件驱动。当时，我对Java语法可精确到BNF范式一级。但2个月后就不是那么回事了，最后考的一踏糊度。考我的人是一个二十三、四岁的年轻人，我记得非常清楚，当时他推了推眼镜，问我：你是不是不懂Java。当时，我只想撒腿就跑，唉，真是丢人现眼。尽管记忆力不好是我的巨大障碍，但有的时候也有其好处。既而我记不住细节，那么我就不去记，这样我的注意力更多的集中在概念和技术的本质上，从某种情况来看这反倒是一种巨大的优势。但用这种优势去应聘能成功么？第三点，如果退一步说，如果用某种语言开发过大系统就算精通该语言。可能情况还是很糟糕。还是以2002年为例子。整个2002年，我使用过的工具有：VC、Delphi、Perl、PL/SQL、Linux下的C、全套J2EE（Java、JSP、EJB）、ASP、PHP、WebSphere、Resin、Tomcat、QT/KDE、KDeveloper、Linux下的FLex和BISON（类似YACC）、Java的Lex和YACC工具，呵呵名字记不清了。数据库有：Oracle、DB2、MYSQL。使用过的应用程序框架有：MFC、VCL、QT。使用过的通信协议：HTTP（VC/Delphi/Java编程）、SNMP、SOAP，至于TCP/IP就不用说了。使用过的Java类库就包含：标准Java类库、Java扩展安全类库、Oracle的Java扩展类库。其中在Oracle的JServer中开发了大量的Java代码。还有，M$的COM/DCOM、MTS、DirectX。其中COM编程一般使用MFC、ATL、DELPHI进行混合编程。至于说Looking，现在已经阅读了6M的资料。至于说那个网管系统，如果细算起来，至少使用8种以上的工具。2002年，我写过的大的项目有三个：宽代记费系统中的记费系统、网络监控系统、Looking。100％单兵作战。代码量8万行，其中6万行是给公司写的，2万行是给自己写的（Looking）。用这样一份成绩单去应聘怎么样？呵呵，有人信么？
