The Game loop

很早之前就研究过关于Game loop的问题。昨天在研究Win32 game window的时候再次牵扯到了该问题。发现以前了解的game loop结构不对。

关于各种Game loop的解析：the game loop 还得仔细再看看才行…

另外还有个基于上边这个文章的视频：

Create a Window in OpenGL without GLUT

You’d better read both of them to gain the full understanding on Win32 and OpenGL setup.

• theForger’s Win32 API Tutorial Part 1-4.
• NeHe OpenGL lesson 1

不太喜欢用GLUT，之前用过，老是感觉很怪，比如有鼠标在屏幕上动，callback interval会变慢。另外也找不到合适的方式来设置game loop。最大的好处就是不需要写太多代码，而且跨平台。

所以还是按照比较正常的win32开发方式来弄咯。NeHe的教程仿佛也没用GLUT。

theForger’s Win32 API Programming Tutorial

顿悟GJK为啥不能直接用来查找碰撞信息

一直搞不明白网上的人说用GJK一定要加margin。我就在想，加个屁的margin啊，直接找origin到simplex边的最短距离的那个vetor就是penetration vector嘛，直接就可以找到contact normal了嘛。结果还是证明我是睁眼瞎。

下图是两个三角形碰撞的两种情况，灰色的六边形是两个三角形的minkowski difference(sum of the reverse)。特性是如果两个凸多边形碰撞，他们的minkowski difference会包括（0，0）原点（那个稍微大点的黑点）。

左边是两个三角形有一点碰撞，实际上可以直接通过原点到simplex的最近的边（橘黄色右上的那个边），作垂线，然后这个垂线就是penetration vector，可以拿来获取碰撞信息，比如，contact normal，penetration depth，contact points啊。显而易见三。

不过右边那个图，因为碰撞且有很大幅度的相互覆盖，如果找最近的那条边的垂线…显而易见已经不再能表示具体含义了。

所以说为啥网上的人说GJK需要加一个很小的margin，这样两个物体的margin相互覆盖的时候叫做shallow penetration，然后可以获取比较准确的contact information。如果是deep penetration，就是相互覆盖太大了，就需要用另外的算法来检测碰撞信息了！！比如：EPA！

刚才又在想，为啥不直接找从原点到整个minkowski sum(difference)的边的最短垂线，仿佛那样就是penetration vector。不过想了一下，再次证明我睁眼瞎…如果以两个12边型相互碰撞…搞不好有24条边要检测；再或者，如果是俩圆形，椭圆形，不规则的圆弧convex…再加上3D…估计再好的电脑也撑不住吧。

所以还是先找simplex（2D是一个 三角形，3D里边是一个四面体，特性是：能包含一个“点”的最小形状）好，方便些。

Seperating-Axis GJK and contact information generation algorithm

1. Use Seperating-Axis GJK metioned here: http://mollyrocket.com/849. Also add some kind of margin when using SA-GJK. So we can saftly do a early out, assume that if dot(A, D) < 0, no intersection.
2. If intersection is found, in other words the SA-GJK does generate a simplex which contains the origin. Then we can use the simplex generated from SA-GJK as intial simplex input to EPA to calculate contact information, such as, contact points and normal, penetration depth.

做个笔记，记录下脑袋里边东西…研究了两个星期Collision detection，看得我抓狂。反正我现在的想法就是这样的…那个所谓SA-GJK，作为一个quick test（当然在此之前还需要broad phase collision detection check），确定两个物体在有margin的情况下是否有碰撞。如果有碰撞（没碰撞，当然就没他们啥事儿了），那就需要更进一步确定是否真正的碰撞，如何碰撞的…

虽然SA-GJK只给出boolean，但是我还是得用啊…浪费半天写了一堆代码总不能不用嘛…

继续研究…

Favicon, Logo更新咯！

上几个星期就弄过Aircapsule的图标。

因为本来就叫AirCapusle,所以理所当然需要一个胶囊一样的图标，于是乎弄出来一个这个：

晃眼一看还过得去…不过当我那它来做64*64的Favicon的时候就出问题了……啥都看不到……乱糟糟一团。再仔细看看，就跟个水壶差不多。这个图标就被暂时否定了。

今天放了半天假，干脆就弄了个具有传统纹样的图标：
 

一个作为图标，一个作为Favicon….
我知道左边那个看起来像一个“囧”…………………参考了挺多东西弄出来个“囧”。

 


可能IE显示Favicon会出些问题，估计是用那个IconWorkshop到处ico图标的时候设置的问题，还要测试一下。

AirCapusle开通啦~~

AirCapsule|空气胶囊 试运行当中…敬请关注。

此windows live space估计会停止更新，虽然本来这个blog都很久没打理了。

主要闲着没事儿，把猪儿子的古董清华同方笔记本搬出来弄了个Ubuntu Server。包括Web server, Samba file server都弄上了。另外因为那台古董键盘有问题，几个字母键都没法用…只好又装个OpenSSH，用来局域网登录。

好不容易想了个将就的名字：空气胶囊|AirCapsule，还画了半天图标…结果还是很不满意。花了几十镑，注册了AirCapsule.com的域名外加DNS hosting…反正弄得我也稀里糊涂，没搞过这些东西，估计弄贵了，花了些冤枉钱，也就认了。

当然，服务器还是那台破笔记本，一开blog我就听到硬盘狂转的声音，吓人啊！
想弄个普通的服务器电脑…看了苹果的Mac mini…将近700镑…抢钱也不能这样啊！还不如直接买8核的Mac Pro！！

现在服务器上也就只有个wordpress，而且还没个像样的主题界面，都是跟着教程做的。上个星期才复习了点CSS。至于php，反正简单，没啥可看的，我又不写啥高级的程序，语法跟函数知道了乱写就行了！

blog的主题界面，在脑袋里边已经有个大概了，估计过几个星期以后能弄出来。

同志们没事儿就不要来黑我了…懒得搞攻防战，估计不爽我就直接拔网线。

以后说不定还可以弄些稀奇古怪的东西，比如游戏开发啊，XMPP，一些特殊网站啊(no porn!!)，简单的教程啊，技巧，经验，资源分享之类的…所以，新手上线，还请关照，多多提意见啊：
AirCapsule|空气胶囊

新年快乐！

虽然英国连三十都没到，国内到了啊！

认识不认识的，大家都虎年快乐！！

下星期放自己一星期假！！
现在先玩儿下游戏都！！

关于绿坝-花季护航

要是你还没听说这个所谓的：

绿坝-花季护航

的软件的话，你就有点落伍了。鼓励同学们勇敢的尝试哈！虽然俺还没机会使用。等我把之前的烂笔记本电脑带回国，绝对装个用哈！

这整个感觉太无稽了，4000多万竟然就做出来这么一个软件。

说它是被“做出来”的话，可能有点抬举了。前几天看了软件的界面截图我就在想，这玩意儿肯定不是一般人能弄出来的。果然！今天看到国内真正强人反编译，分析以后，更让我相当之好奇，吃惊，就这么个东西？！4000多万？！还好意思说每台销售的电脑都要预装，附带？！

这儿偷点数据，哪儿抄点代码！违反开源代码协议！东拼西凑出来的东西，漏洞百出，还打算强行安装？用了4000万纳税人的钱，反过来还美其名曰：免费试用1年……这也太无耻了嘛……

简直是本世纪第一大笑话！现在好多世纪咯？！21世纪了哇？！

说实话，哪个要是给我100万……对嘛，借我100万，找几个人立马可以在我现在做的WindChime Project里边加入家长监控功能。而且是实时监控，父母随可以了解小屁娃在网上干啥子，弄点更无耻的还可以直接强制远程关闭电脑之类的。

现在电脑识别图像算法不完善，只能作为一个最基本的筛选工具。当发现可疑图片，网页文字的时候，可以直接通过XMPP Jingle发送即时数据到家长的手机，笔记本，等等移动设备上，让人来判断是否是有害信息，并对算法进行纠正，然后整个软件会自我学习。如果我没记错的话……当年大二学的Subsymbolic Processing and Neural Networks（亚符号处理和神经元网络，是这么翻译？！）里讲到的差不多就这么一个东西，自我完善的神经元网络！仿佛还是需要大量数据来训练Perceptron network。不过反正中国人多三！！数据好办的很！！那一门我也就只记得这些咯！无限难！

我描述的软件高级哇？！我这种三流程序员都能设想些更实际，实用的……那么随便给谁4000万也都可以做个真材实料的嘛！！！

至于为啥这个软件可以被钦点……估计相关的人脑壳都被屎敷了一遍……当然也不排除相关的人脑壳本身就是屎的可能性……

 

总结:鼓励大家尝试哈滤霸的威力，不过最好在烂电脑上用，要不到时候打个文件都莫名其妙被直接关掉，没有保存……之类的，就安逸咯！

哎……最为一名留学生，想爱国，真的要有点能耐，真的不容易啊！给点机会好不好？！

跩圆了！

上班都可以写Blog！哇哈哈哈！

虽然都要下班了。

 

都没得人了，该弄的东西都弄得差不多了！

最后半个小时就休息哈！干点腮边打网的事情！

 

比如，无限跩的写日志等下班！

更多关于 External component & Data synchronization

Access Model
Description

Open
Any entity may subscribe to the node (i.e., without the necessity for subscription approval) and any entity may retrieve items from the node (i.e., without being subscribed); this SHOULD be the default access model for generic pubsub services.

Presence
Any entity with a subscription of type "from" or "both" may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921).

Roster
Any entity in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems (see RFC 3921).

Authorize
The node owner must approve all subscription requests, and only subscribers may retrieve items from the node.

Whitelist
An entity may subscribe or retrieve items only if on a whitelist managed by the node owner. The node owner MUST automatically be on the whitelist. In order to add entities to the whitelist, the node owner SHOULD use the protocol specified in the Manage Affiliated Entities section of this document, specifically by setting the affiliation to "member".

修正昨天说的。影响到PubSub External Component的应该有两种Access Model，就是上边所说的Presence和Roster。

不过我实在不知道把Publish Subscribe Service做成一个External Component有多大好处。我之前只是简单觉得，可以把它放在另外一台电脑上运行，而且不一定局限于连接Openfire XMPP Server，以后过度期间还可以连到ejabber啊之类的XMPP Server。

不过现在看来并不能简单得单一的作为一个External Component，因为一旦牵扯到Presence Subscription和Roster，就必须要相关的User data，而这些数据都储存在XMPP server上边，并不能是直接就可以想拿就拿来用的。

也不可能直接调用数据库！首先太慢！其次Server不一定立刻存储数据到数据库。

必须通过发送接收相应的XMPP packet来交换数据，实现数据同步。

现在想的，如果要用External Component，首先要写一个Internal PacketInterceptor Plugin，监视所有的Presence subscription Packet。因为Openfire server api里边没有presence handler处理这种Packet：

<presence to='juliet@example.com' type='subscribe'/>

不过倒是有IQHandler专门可以用来处理Roster add and delete packet：

<iq from='juliet@example.com/balcony' type='set' id='roster_2'>
  <query xmlns='jabber:iq:roster'>
    <item jid='nurse@example.com'
          name='Nurse'>
      <group>Servants</group>
    </item>
  </query>
</iq>

所以同步Roster和Presence Subscription还是可以实现的，当然External Publish Subscribe component也就可以实现了。

只是不知道最后会不会太慢。

如果不用External Component，那就简单了，之前写的东西，修改一下，就可以用了。