摘要: 随时更新中。特地整理了一下，供期望了解本blog或者是本人的朋友们参考:)  阅读全文

hmmm... 整ppt整习惯了，懒得长篇大论写了，偷个懒... 其中的内容已经尽量用简单、直观的方式来表述了，较浓缩，大家将就看。

随便说说。其实所谓微软战略，大家已经把它研究得非常透了，比方说HBR等等。说穿了微软的核心就是构建一个OS平台，平台的两边，一边是普通用户，一边是开发者。微软平台策略的核心在于，OS用户收费，软件开发者则全免费，为什么？因为没有下游用户自然也就不会有收入，而上游开发者越多，下游用户就越多。实际上微软相当于是在免费补贴开发者，这里我再帮各位换个说法，实际上开发者是在用自己的职业发展前景、及将来的差异化竞争力为代价，来跟微软换取开发学习所需付出的成本。什么叫挖坑，这就叫挖坑，而且是灰常有水平的大坑，呵呵。这跟游戏机平台完全不一样，比方说XBOX 360，微软宁可以低于成本价把主机卖给用户，然后从开发商这里收授权、销售分成等大头。

有很多微软开发者都在自怨自艾，尤其是搞Web应用的，说什么深入不下去啦，新东西太多啦，竞争激烈啦，技术发展太快啦，等等。其实我觉得关键在于这些开发者有没有理解微软的平台策略，“开发者免费，使用者收费”，这不仅意味着门槛的极大降低，同时也意味着，微软是不可能放弃对你思维方式、知识结构还有技术依赖性的影响的，前者意味着竞争激烈，个人技能缺乏壁垒，势必疲于奔命，同时诱导开发者之间的充分竞争对微软自有应用产品也很有利；后者则意味着微软将不得不以快速更新平台技术的方式来牵引应用，而永远都不可能让你的创新走到它的前面，它绝对不会给你这个时间差 (这一点现在M$是越做越纯熟了，呵呵)，因为它要从各个层次垄断和主导整个平台的技术发展，而且，office/vista等微软自有产品卖得越是不好，它越要快速升级开发技术，这同时也就决定了，开发者偶有创新也只可能是低层次的创新，你所谓的new idea最终多数也就落得个被微软快速合并进平台技术的命运，这就不难解释为何.net为何更新速度如此迅猛，应用框架为何推出如此之多，却鲜有大规模开源社区对其给予真正有影响力的实质性关注的缘故了。

所以，说白了，单纯的开发者只是微软平台中的一枚棋子，切莫自视甚高，切勿以为自己是真正地从M$那里白赚到了。真正久经沙场的老鸟们都知道，会几门私有平台技术是不值钱的，真的没啥值得夸口的，发展面窄得很，贬起值来却一泻千里，因为从商业本质上讲，你是把握不了自己命运的.... OK....白扯一通，权当自己打击自己，余下的意思，就得靠各位自己悟了，当然，有人理解不了嗤之以鼻我也是能够理解的，呵呵。路该怎么走，萝卜白菜各有所爱，有人喜欢独自冒险，有人愿意被牵着走，有人更愿意削尖脑袋挤进M$，这就只有自己才知道了。但至少看问题看得明白点，总是没有坏处的。

后注：呵呵，我可不是为了打击大家学习积极性啊，更不是贬低微软，说微软的这种策略是划时代的伟大创造是一点都不夸张的。鼓励各位想开点，结合微软的策略，提醒大家积极寻求自己的差异化发展，才是吾的主要目的啊~

从校准过程及其采用的普通摄像头来看，撇开OCR不谈，应该是个基于块的运动检测过程，也就是2D视频编码用来帧间预测的技术，已经很成熟的dd了...只不过换了种展现形式吧...

想了解一下星际2 3D图像引擎的细节和技术动向吗？这篇由Blizzard员工所攥写的Course Paper绝不会让你失望的！其主要涵盖了星际2 Cut-scenes渲染的技术内容，面向中等水平技术人员，且非常口语化，强烈推荐！

SIGGRAPH 2008
Advances in Real-Time Rendering in 3D Graphics and Games Course [Part-5]
Starcraft II Effects and Techniques (.pdf, 4.2MB)
by Dominic Filion, Rob McNaughton, Blizzard Entertainment

随便写写，向大家介绍一下Firefox 3中信息搜集、管理方面的杀手级功能：Awesome Bar。众所周知，IE的那种层级式收藏夹已经过时了，没人愿意用子目录来手工整理数以百计的书签。在Firefox 3中，书签管理、标签(tags)归类的功能得到了空前强化，基本上，除共享之外，其完全可以用来替代目前流行的网络书摘应用，如delicious、QQ书签等；而Awesome Bar作为书签及tags查询的综合界面接口，其易用性也让人爱不释手。

基本界面：


实现原理：
使用Firefox内置的SQLite引擎存储所有的用户访问信息，其来源包括历史、收藏夹、标签、已访问的url、已访问的网页标题、页面元数据等，然后根据用户输入的关键字，对其进行实时的部分字符串匹配查询，罗列出所有匹配结果，并按照一定算法排序，从而帮助用户迅速找到所需的目标网址。简而言之，相当于是用户网页访问信息的本地搜索。

匹配信息来源：
历史url、收藏夹、标签(tags)、曾访问过的网页标题

查询排序依据：
1. 访问时效性
2. 访问频率
3. 统计访问次数
4. 字符串匹配程度

界面功能：(*为常用功能)
1. (*)bar右边的下拉按钮：显示本机访问频率最高的网址列表
2. (*)bar右边的星星标记：单击—立即收藏当前网页至"未整理书签"，不添加tags；双击—收藏当前网页，并指定其tags及存储位置
3. bar左边的网页标记：显示当前站点信息，包括统计访问次数、页面元数据等
4. bar右边的订阅标记：订阅当前网页中的RSS

小技巧：
Q: 如何永久性删除Awesome Bar筛选出来的一些条目
A1. 用光标键在下拉列表中选中该条目，然后按Del或Shift+Del....
A2. 根据列表中星星等UI提示，判断该条目所处位置，然后从书签或历史中删除

一般资料整理方式：
1. 访问网页时，仅需点一下星星即可将其迅速收藏至"未整理书签"
2. Ctrl+Shift+B，打开书签管理器，在“未整理书签“中，逐个修改收藏书签的标题，添加tags，以体现特色和分类
3. 可选：在书签管理器中新建一个”已整理书签“目录，将所有已添加了tags的书签全部移至其中，保持“未整理书签“为空
4. 接下来，用Awesome Bar来搜想要的tags、标题关键字吧！

一个典型应用实例：
比方说，我希望查找某个自己曾经访问过的盟军文件格式汇总网页，该网页也许已收藏过了，也许没有；随便输入个“盟军”试试，ff列出了所有匹配结果，注意其中的匹配关键字已被加粗，有星星标记的记录是已收藏网页，星星的左边标记是其书签所关联的tags；


Ok, 把"commandos"也输进去，进一步缩小范围，注意此时只有同时具备两个关键词的记录才会被显示出来


继续添加一个关键字"文档"，其结果恰好是我需要找的那个网页。地址栏居然也能当搜索栏，是不是很酷？:)

2008-5-29
项目未死，临时暂停，一个月后重开。

2008-5-6
Rendering架构整理；多纹理管理；Blp多重纹理调试支持；dbc数据库加载优化；ArcBall摄像机；等等。hmmm... 适当地踩踩刹车是有必要的，为了以后能开得更快

2008-5-5
正确的替换纹理查询；自.mpq中自动加载.m2、所有.dbc和.blp纹理；正确的纹理切换与渲染次序；初步的Alpha混合；基本显示交互。


2008-5-3
发现.m2模型的纹理换装很麻烦，替换纹理必须从多张.dbc表(Database Client)中进行联合查询方可得到。几乎每一张.dbc、每一条查找路径都必须用代码封装，人都累死...而且，其实目前对许多.dbc字段含义及交叉引用关系普遍理解并不完善，再加上WoW中庞大的资源组织规模，盲目地封装类显然自缚手脚...一怒之下添了个sqlite进去，干脆8择手段一点：在 rendering之前将所需.dbc从.mpq中一次性读入内存数据库，复杂查询只需用sql语句封装一下即ok... hmmm so neat and flexible~

2008-5-2
添加了自动从.mpq中加载.m2模型及.blp压缩贴图的支持，可以将.blp中的mipmaps导出成.png供调试

2008-5-1
opengl+glut+glew。初步模型+纹理，无纹理特效、无骨骼动画、无粒子和丝带效果... 太多的无。8过8要紧...慢慢整~=)


2008-4-30
Why WoW? 原因是多方面的：1. 长久以来，Blizzard都是欧美系的一个另类典范：它一直都不以画面效果领先者自居，但有趣的是，几乎每一款BLZ的作品却总是会树立起一个标准，一 个最低限度画面技术效果(非美工...Blz美工超强...)的门槛，恩...了解什么是标准本身就很有意义；2. 作为画面效果的后进者，Blz所采用的技术相对保守，但覆盖范围全面，取舍合理，WoW发展至今，资料也相对完整；3. 兼顾固定管线和Shader，配置要求很合适，对于只有ATI 7500的吾来说....4. 资源极大丰富，且质量和规模均体现了一定工业强度... 对于爱好者而言，不比那些有美工搭档的从业者，有资源才有一切可能...

     摘要: 星际争霸2虫族公布. 内附高清截图和720p高清视频下载.  阅读全文

It's well known that the H.264 and AAC decoding has been supported by the new Flash Player 9 Update 3(9.0.115), which may mean a whole new era for high-definition video to begin. In order to witness the great power of new Flash player, I did some experiments on H.264 encoding and compared their results with the traditional FLV videos (a variant of H.263). Generally speaking, the comparing result is really impressive: Both videos of FLV and H.264 (within an encapsulated form of .mp4) could be progressively downloaded and played online. With some fine-tuning of the H.264 encoding parameters, it’s possible to shrink the video size by half and while at the same time to gain equivalent or even much better graphical quality than the FLV one! Really awesome, isn’t it?:)

Below is one of my prelimentary tests, a 9.8MB demo for starcraft 2. As you can see, the quality of this H.264 video is practically quite close to a FLV equivalent with a fairly high bit-rate of 1200 kbps, but in the matter of fact, its average bit-rate has only 550 kbps, which could be affordable for most of the typical users on Internet I think.

At the end of this article I packed up some troubles that I'd counted before, and  I also provided their answers for convenience. Hope that they may also be useful for you.

= Concise F.A.Q for working with H.264 in Flash Player =

Q: Why can’t I play the demo in my browser!?
A: Adobe Flash Player 9 Update 3 (9.0.115 or above) and related plug-in are required. Plz refer to here for further information.

Q: How can I encode my video clips with H.264 codec?
A: x264 is my personal favors to do that job. It's open-source and totally free.

Q: How can I place the H.264 video clips in my web pages?
A: You‘ll need some Flash video player and embed them in your page just like a normal .swf object. As far as I know, there are 3 typical online players to choose: Vcastr (light-weight), JW Flv Player (moderate) and FlowPlayer (comprehensive). They're all free. You can also use the SWFObject library to facilitate the configuration of these embedded players.

Q: Why is my progressive H.264 video not playing in the player until entire file is downloaded?
A: One important thing about playing an H.264 video file as progressive download is that the moov atom for indexing needs to be located at the beginning of the file, or else the entire file will have to be downloaded before it begins playing. Unfortunately, tools such as FFmpeg place this information at the end of the file by default. You should use qt-faststart to fix this annoying problem.

2/1/2008
There is so many friends curiously think I'm only interested in Gamedevs, Graphics and Geeks (3G for abbr. ? -_-b).... As my official denial and fight-back (not so much seriously^^),  I have prepared a little charming thing (which was implemented from scratch by myself) here for you guys, and I hope that you could find something more than meets the ears... Attentionl Managed DirectSound and .NET Framework 2.0 are required.

Download: Streaming Audio Sample (cancelled...)


2/7/2008
Today I decided to update this fun-project with an improved sample that supports essential streaming MPEG-1/3 (a.k.a. MP3) decoding. Although as far as I know DirectShow does not suit for the requirement of frame-by-frame audio splitting and decoding, which is absolutely needed for an as-neat-as-possible streaming media project, I finally found something even more interesting – FFmpeg, one of the best multimedia projects in F/OSS world. In this following sample, the MPEG-1/3 core was ripped and slightly modified from FFmpeg, and compiled with /clr option by using VS2005. The main difficulty I have met is the terribly slow running performance when debugging a CLR decodec. It’s really hard to drive a .NET based real-time MPEG-1/3 decodec in debugging environment. The reason lies behind this is that there is no optimization at all. But when we run it directly out of the IDE, things become more better by the mercy of  JIT optimizations. From a perspective of Geeks that always be in pursuit of 100% perfect, the final effect is not wonderful enough and it may need some further fine-tuning. But for an experimental try-out, it’s fairly good I think:-)


2/10/2008
Yesterday when I decided to dig somewhat deeper into the MPEG-1/3 core to find why the debugging performance is too slow, I was shocked. I found several strange intrinsic functions that used some __asm blocks to try to improve the performance of native code. "Native code optimization in a managed running context", bad smell huh? In fact, that’s the REAL answer of the whole evil question. Some further profiling show that when these “native-optimized” intrinsic functions were called, there were so many context switches occurred between the managed and unmanaged boundary back and forth frequently, leading the debugging performance drop to an unbelievable low extent. After being aware of above situation, I quickly changed the compiling option of /clr (which supports mixing calling model) to /clr:pure (which could be applied to ensure that there will be no native executable codes exist in the assembly anymore), and I also replaced all of these __asm blocks with some equivalent operations by using normal C++/CLI sentences, then rebuilt the whole project. The result was so impressive: the debugging performance in IDE was dramatically improved over 10 times than what I got few days ago! Now there would be no problem to drive a pure .Net MPEG-1/3 core with all IDE debugging functions enabled in real-time!

Download: Streaming MPEG-1/3 Sample (updated, 43.2KB)