基于插件的引擎设计

这篇小文是我读“Building an Engine Plugin System”(需翻墙)随手留下的一些笔记。

开始正文前,先无责任评论两句吧。bitsquid是一个强调动态(各种reload),极简设计(接口知识最小化),轻量级(核心不到20万行)的引擎,跟俺口味很贴近,所以俺一向比较关注他们的动向。这是个小团队,虽然网站上没啥信息,引擎也未公开放出,可是blog的水分很少,质量比较高,是俺的菜。

按照传统套路,先啰嗦一番“非插件化设计”的弊端:

想扩展现有行为,就得修改代码,重编引擎。(隐含工作量太大——获取全部代码和依赖的库,架设所有build环境)

一旦开始有了本地改动就得维......

[译] 不要说谎 (Don't lie.)

作者按:

本文是两年半前翻译的一篇文章,译于[2011-11-05](修订于[2014-03-22]),原文发表于[2011-10-04],出自 DEADC0DE 的 blog(需翻墙),原文在这里(需翻墙)。

现在我仍记得,初读此文时,脑海中反复回响着的林锐博士的一句话:“做一个真实,正直,优秀的科技人员。”

在漫长的职业生涯中,一个程序员会不断面临各种主观和客观的压力,前者比如视野,品味,学习能力和天然惰性,后者比如项目进度,主管偏好等等。能不能在面临这些实实在在的压力时,仍有一丝不苟的操守,认真对待自己写下的每一行代码,这对于有追求的程序员几乎总是一个艰难的选择。我相信,凡是热爱编程的程......

为什么从本质上讲,渲染逻辑不适合放到子线程中去?

作者按: 本文成文于一年前 [2013-01-13],修相关的 bug 修得郁闷,遂成文,[2014-03-20] 整理旧文档时稍作修订。

为什么从本质上讲,渲染逻辑不适合放到子线程中去?

因为渲染是一个需要大量的 CPU 和 GPU 同时参与的操作,无论如何组织架构,在事实上均难以避免高频和实时的较大数量的数据的更新和传输,这是渲染(尤其是 大量动态物体的数据在不断被改变 的情况下)的本质决定的。

从实践上看,那些线程化渲染(threaded rendering)的常见做法中,勉强去做每帧同步,或隔帧同步,或延迟1-N帧同步,均会导致大量的细节被暴露给整个架构。此亦从根本上违反了软件开......

客户端动态预测技术和延时补偿技术

以前在做飞机游戏 (Wings of Fate) 的时候,实现过一个改善同步的技术,用来降低高ping客户端的延时感受(客户端的动态预测和延时补偿技术)。前两天跟朋友L聊天时表达了一下,觉得有记录下来的价值,遂有此文,以备日后参考。

有A和B两个客户端,在B移动时,A的客户端上会以一定频率收到B的移动信息同步。如果总是等到收到B的信息后再去被动地移动,那就会导致在A的机器上,B的移动总是滞后的。这一般是典型MMO如WOW的做法,而对某些类型的游戏(fps,空战)来讲,这种延迟是难以接受的。

一个做法是,A总是通过B之前的移动去预测其接下来的移动情况(Q3的做法),这样有极大的可能(实测至少......

知识共享许可协议
本作品由Gu Lu创作,采用知识共享Attribution-NonCommercial-NoDerivatives 4.0 国际许可协议进行许可。