另一个世界的旋律『午夜』

Part I Translation

February 6, 2012

Living With Facebook, and Living Without It

To the Editor:

“Facebook Is Using You,” by Lori Andrews (Sunday Review, Feb. 5), offers a frightening overview of the use and misuse of data aggregation on the Web, but that hardly supports pegging Facebook as the primary culprit.

“脸谱网正在利用你”，洛里·安德鲁斯在二月五号的星期天回顾中写道。它给出了一个骇人的对用户数据不合理使用的概况，却很难支撑将脸谱网视作罪魁祸首这一观点。

Extracting data from private e-mail messages and Web browsers to inform credit, insurance and employment decisions threatens privacy and creates opportunities for stereotyping and outright discrimination. But the only practice Ms. Andrews attributes to Facebook is tapping information voluntarily shared through “likes” and semipublic postings to show users more relevant advertising.

从私人邮件和网页浏览器中提取数据以获得信用卡、保险和职业信息，这样的行为已经威胁到了个人隐私，并且让对群体的既定概念以及公开的歧视变得更为可能。但安德鲁斯女士唯一提到的，是脸谱网通过窃取用户自愿以“喜欢”按钮和半公开的日志形式分享的内容，来推送相关的广告。

For example, because I “like” Aretha Franklin, Facebook showed me an ad for her coming Radio City concert rather than, say, one for a Kenny Rogers boxed set, mountain-climbing gear or cupcakes. As a result, I got tickets. This strikes me as a win-win, and one of the more benign if not positive commercial uses of social media.

举例而言，由于我在艾瑞莎·富兰克林的公共主页点击了“喜欢”按钮，脸谱网便倾向于向我展示艾瑞莎·富兰克林即将在纽约无线电城音乐厅举行演出的广告，而不是肯尼·罗杰斯的CD套装、爬山装备或是蛋糕。也正是这样，我获得了音乐会的门票。这的确让我觉得是一种双赢。即使这种对社交媒体的商业使用说不上那么的正面，对我而言起码也能算是一种相对良性的行为。

Facebook may well contribute in more nefarious ways to the privacy concerns Ms. Andrews identifies, but her article does not make a case for it.

脸谱网也许的确在安德鲁斯女士所指出的，关注个人隐私这一方面以一种不好的方式发挥作用，但在她的文章中却并没能提及。

JEFFREY S. TRACHTMAN
New York, Feb. 5, 2012

To the Editor:

Re “The Death of the Cyberflâneur” (Sunday Review, Feb. 5):

Evgeny Morozov, questioning the Facebook founder Mark Zuckerberg’s suggestion that everything is better when shared, rightly asks, “Why this fear of solitude in the first place?”

叶夫根尼·莫罗佐夫，质疑脸谱网创始人马克·扎克伯格的“分享让一切变得更好”这一口号。他问道“首先，为什么人们会有种对孤独的恐惧感？”

Facebook isn’t intended for introverts like me. I have only a few strong social bonds. In superficial dialogues, like those about a hip new restaurant or a celebrity’s faux pas, I prefer not to speak.

像我这样性格内向的人是不适合脸谱网的。我只有少数一些紧密的社交圈子。而一些随便聊聊的话题，比如一个时髦的新餐厅，或是某个名人的出糗，我想我是不会参与的。

Regardless, three years ago, I signed up for Facebook. Within weeks, I hated myself on Facebook — needy, snarky, self-important. I also lowered my opinion of my “friends,” who repeatedly posted insipid thoughts in the hope of validation through reply.

无论如何，三年前，我还是注册了脸谱网的帐号。仅仅数周之内，我开始痛恨在脸谱网上的自己——那是一个缺乏自信的、不受欢迎的、以自我为中心的人。同时我也降低了我对某些朋友的评价，因为他们一遍又一遍地贴一些毫无新意的留言，并且期望着【通过别人的回复来获得存在感？最后这句应该怎么翻来着……】

Six months ago, I quit Facebook. Today, I am more educated and enlightened by visiting just about any other site on the Web. I do this alone, and contrary to Mr. Zuckerberg’s claim, I prefer it this way.

六个月前，我注销了脸谱网的帐号。如今，我通过浏览一些其他的网站来使自己变得更加博学多才。这都是我自己做的，而并不像扎克伯格先生所声称的那样。我想我更加适合前者。

JONATHAN CAREY
San Francisco, Feb. 5, 2012

Part II Issue

Government should offer college and university education free of charge to all students.

明日继续Issue部分。

这是给狐狸的辩论赛思路。

反方命题：距离不是爱情的绊脚石。

了解对方命题的实质，了解可以反击的重点。

对方的命题是距离是爱情的绊脚石。

对方这个命题承载的意思是：

第零、距离和爱情有直接的因果联系。

第一、任何距离都有可能成为爱情的绊脚石，太长的、太短的距离都一样。

第二、距离直接阻碍了爱情的发展。

所以千万记住不要什么“因为对方说太长的距离是爱情的绊脚石，所以我方举例说太短的距离也一样可能是爱情的绊脚石来反驳”，这尼玛绝对是自寻死路。

假使对方比较蠢【其实是我比较蠢，那么大概对方的主要切入点不外乎是：“太长的距离是爱情的绊脚石，并用分隔两地的情侣是如何不堪忍受寂寞而分手的来举例。”。

这个时候，可以反击的点有很多，我在下面逐一列出来：

反击之一：直接摧毁该命题的逻辑——距离和爱情没有直接的因果联系。

天天粘一起爱情就会永葆活力么？相隔异地就注定是悲剧的结局么？答案是否定的。

举例：

就如同考试是用来检验你的能力的。然而卷子出难了，你的分数低了，你的能力就差了么？卷子出简单了，你的分数高了，你的能力就强了么？虽然分数能够一定程度上反映出能力，但是你所拥有的能力是固定的，不会因为卷子的难易而发生变化。爱情亦然。身体之间的距离也许会变得遥远，但如果有爱，心就不会离开。所以，爱就在那里，不增不减，与距离无关。既然距离都无法影响到爱情，那么距离当然就不是爱情的绊脚石了。

反击之二：反击该命题的模糊性——距离是爱情的绊脚石，那么到底怎样的距离是爱情的绊脚石？

这件事情一开场就要做，因为这条很阴险，对方无论如何逃不掉对他进行的人身攻击的。

逼对方做出清晰的回应，不然就用“连对方都搞不清楚怎样的距离是爱情的绊脚石，又如何来信誓旦旦地证明该命题呢！”来抽对方的脸www如果对方被逼无奈给出了任何清晰的负面例子，那么对应见下方举例。

举例：

发霉的面包让你吃坏了肚子，你可以抱怨，可以不爽，但你绝对不能用“面包是健康的绊脚石”来昭告天下。『与“对方给出的负面例子”相呼应』

反击之三：反驳阻碍一说——距离不是爱情的阻碍，因为距离是爱情的考验。

身体之间的距离变得遥远，就更加能够考验两个人心灵的意志。所以距离之于爱情，就好象试卷之于能力，都是一种测试，一种考验。正因为如此，你完全不能说“试卷是能力的绊脚石”。『参见分析一的举例』于是你也不能说“距离是爱情的绊脚石”。

举例：

晴朗的夜空，天上繁星闪耀。牛郎织女泪眼盈盈，隔河相望。世界上最遥远的距离，不是生与死，而是你就站在我面前，我却无法牵起你的双手。只有每年的七月初七，人间的喜鹊才能飞上天去，在银河为牛郎织女搭鹊桥相会。如果爱情会因为距离而褪色，七夕又怎会作为有情人的佳节广为传颂？牛郎织女的故事又如何能够这般流传古今？越是遥远的距离，才越是能彰显爱情的珍贵。距离，自然不是爱情的绊脚石。

反击之四：正面攻击——距离能够促进爱情。

朝思暮想是怎么发明出来的，因为距离。朝思暮想是褒义的还是贬义的？朝思暮想是用来形容爱情的浓烈，当然是褒义的。因为距离而诞生了与爱情相关的褒义词，距离当然不是爱情的绊脚石了。

什么叫做距离产生美，什么叫做小别胜新婚。古人给了这么好的例子，自己展开。

暂时就想到这么几点。

辩论的精髓在于掌握逻辑谬论。并不是要说真的让你去以理服人，而是要以“一眼看上去正确”的理去服人。同时，精彩的发言能够激发聆听者的感情，同时掩饰道理的不足。如果打分者能够有“虽然不知道在说什么但是好厉害”的感觉，那你就胜利了一大半了www

http://zh.wikipedia.org/wiki/%E8%AC%AC%E8%AB%96

这个推荐去看一下～

央视批评百度的事件愈演愈烈，坊间大多是抱持狗咬狗的观望态度。

试着分析总结了一下，有如下的表格：

所以，为什么焦点在央视而非百度，原因有三——

第一、百度的问题并非集中爆发而是长久存在，监管应是持久可控的而非突击钓鱼的；
第二、百度所滥用的权力是由其垄断地位带来的，试问这个垄断地位又是如何形成的；
第三、所有互联网业者都在关注的是央视一连串媒体行为背后的国家互联网政策变动，而不是百度究竟做了些什么。

在公司的电脑上装了LiveWriter，所以又可以更新博客了～

瞬间一个多月过去了我又没有更新博客。

还有三天蓝白截止，刚把程序部分完成，开始应用。

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

首先把要点罗列一下。

一、弹幕中文本位置的计算（新）

以前是完全用三维点进行旋转运算的，现在改成向量操作了，效率瞬间提升了很多。
首先，弹幕区域是个矩形平面，所以它有两个单位方向向量Ux和Uy。
在未进行旋转之前，Ux就是标准的X轴正方向单位向量，Uy就是标准的Y轴正方向单位向量。
那么我们可以把这个弹幕平面，放到由弹幕基准点和两个单位方向向量所组成的坐标系中。
于是我们可以将任何弹幕的旋转动作，视作该坐标系的旋转动作。
也就是说，任何旋转动作的结果，都是改变了Ux和Uy。
所以结论是，在未经过旋转之前，任何一个字在弹幕区域中所处的位置，就是它距离弹幕基准点的横向与纵向长度。
那么在旋转过之后，任何一个字在弹幕区域中所处的位置，就是它原本距离弹幕基准点的横向长度乘上Ux、纵向长度乘上Uy。
原本每个字的位置都要用矩阵旋转计算一次，现在则是只要旋转一次坐标系，剩下的都是常数乘向量，计算量很小。

二、弹幕内容修改所导致的弹幕位置重新计算

1.弹幕属性的修改

修改了 字号、旋转角、基准点 将导致整个弹幕区域中的字符坐标重新计算。
重新计算的流程如下：
1）根据旋转角计算Ux、Uy。
2）根据前一个字符的位置计算后一个字符的位置，推导出其距离基准点的横纵向长度。
3）横向长度乘以Ux、纵向长度乘以Uy，得到字符的基准点坐标。
4）通过字符基准点坐标算出字符方格的四个坐标。
但是这里有个可以优化的地方。
旋转角的修改需要重新计算Ux和Uy（见上节），也就是说要从（1）开始做。
字号的修改需要重新计算横纵向长度（见上节），也就是说它是从（2）开始做的。
而基准点的修改则是可以通过进行一个坐标偏移来实现，也就是说，它是用坐标偏移的方法盖过了（1）、（2）和（3）的流程。
显然这三者的所耗费的时间是从高到低的。所以算法中要加以区分。

2.弹幕文本的修改

这个说起来挺简单的。
如果你在第二行的第二个位置插入了字符，你只需要重新计算第二行中第一个位置之后的字符。
如果你删除了第三行，你只需要重新计算第二行之下的行。
依照这种逻辑进行。

三、时间轴模拟器与弹幕的动态属性

这个和动态属性有直接关联。所以放在一起说。
它实现的有Play()、Pause()、Stop()方法，还有一个TimeNow属性和一个Tick事件。可以将这个东西视作任何视频播放器的时间轴接口。
比如说一条弹幕是在4秒（4000毫秒）内从(0,0)移动到(40,40)的。Tick的间隔是50毫秒。
也就是说每Tick一次，x和y轴坐标都有一个40 / (4000 / 50) = 0.5像素的偏移量。
所以，弹幕的动态属性在设定上，需要设定弹幕属性中可变属性的变化方法，而在需要进行模拟的时候，则要与时间轴模拟器的Tick事件绑定。
换言之，弹幕属性是固定值，而动态属性则是根据时间轴变化的值。但在每一个时间点上，动态属性又是固定的值，只有当每次Tick事件发生时，它的值才会根据变化方法产生变化。
所以，我现在是把动态属性当作弹幕属性的附加模块来做的，模拟的时候用LinkToSimulator()方法将动态属性绑定到模拟器上就可以了。分离静态与动态属性的好处是解耦合。今天想把基准点线性变化了，明天又想把旋转角线性变化了，后天又想把缩放比线性变化了，大后天又想函数式变化了，如果把所有这些属性都扔在弹幕属性里，结局肯定是弹幕属性变得越来越拖沓，一个类二三十种属性，谁受得了。只有好的逻辑结构才能有好的扩展空间，这是我一直坚持的。
而2D的特效怎么处理我还没想好，还要等遇到了再考虑。

四、结语

这几个要点实现了，设计器又有了很大的飞跃，不过离我想象中的还是有距离。
效果插件部分准备拿Lua写。最终的UI准备拿WPF来做，发觉T君也已经开始看WPF了所以UI部分我先放着，先把底层都完善了再说。

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

然后是现在弹幕的接口。

    public interface IComment : ISelectable, IVisible
    {
        string Name { get; set; }//名称
        ICommentAttributes GetIAttributes();//获得弹幕属性接口
        ICommentInfo GetIInfo();//获得弹幕文本接口
    }

    public interface ICommentAttributes
    {
        double X { get; set; }//X坐标
        double Y { get; set; }//Y坐标
        double Z { get; set; }//Z坐标
        double RotationX { get; set; }//X轴旋转角（角度）
        double RotationY { get; set; }//Y轴旋转角（角度）
        double RotationZ { get; set; }//Z轴旋转角（角度）
        double Alpha { get; set; }//透明度
        int FontColor { get; set; }//颜色
        double WidthScale { get; set; }//横向缩放比
        double HeightScale { get; set; }//纵向缩放比
        int FontSize { get; set; }//字体
        double AppearTime { get; set; }//出现时间
        double Life { get; set; }//持续时间
        double DisappearTime { get; set; }//消失时间
        void SetAttributes(double? X, double? Y, double? Z, double? RotationX, double? RotationY, double? RotationZ, double? Alpha, int? FontColor, int? FontSize, double? AppearTime, double? Life, double? WidthScale, double? HeightScale);//属性设定函数
    }

    public interface ICommentInfo : IEnumerable<TLine>
    {
        string[] Lines { get; set; }//弹幕文本以行来处理
        string Text { get; set; }//弹幕文本以整体处理
        IChar GetIChar(int LineIndex, int CharIndex);//获得字符接口
    }

    public interface IChar : ISelectable
    {
        char Info { get; set; }//字符内容
        bool IsFullWidth { get; }//字符是否为全角
        double X { get; set; }//X坐标
        double Y { get; set; }//Y坐标
        double Z { get; set; }//Z坐标
    }

    public interface ISelectable
    {
        bool Selected { get; }//是否选中
        bool Select();
        bool Deselect();
    }

    public interface IVisible
    {
        bool Visible { get; }//是否可见
        bool Show();
        bool Hide();
    }

毕设要冲优所以忙爆了，随便扔点进展上来……

弹幕处理类中现在提供的处理方法如下——

#region - 选择层 -

//选择处理对象
public void SetEditList(CommentEditKind EditKind)

//通过弹幕索引选取弹幕
public void Select(int CommentIndex)

//通过弹幕索引表选取弹幕
public void Select(int[] CommentIndexes)

//通过弹幕索引取消选择
public void Deselect(int CommentIndex)

//通过弹幕索引表取消选择
public void Deselect(int[] CommentIndexes)

//通过编辑列表的索引取消选择
private void RemoveAt(int PickIndex)

//清除编辑列表
public void Clear()

#endregion

#region - 时间设置 -

//设置出现时间
public void SetAppearTime(double AppearTime)

//设置相对出现时间（在原本的出现时间上变化）
public void SetAppearTimeRelative(double RelativeTime)

//设置递增出现时间
public void SetAppearTimeStep(double StartTime, double StepTime)

//设置存活时间
public void SetLife(double Life)

//设置消失时间
public void SetDisappearTime(double DisappearTime)

//设置递增消失时间
public void SetDisappearTimeStep(double StartTime, double StepTime)

#endregion

#region - 排序 -

//以出现时间排序
public void SortByAppearTime(SortOrder NowOrder)

//以消失时间排序
public void SortByDisappearTime(SortOrder NowOrder)

//以存活时间排序
public void SortByLife(SortOrder NowOrder)

#endregion

#region - 颜色处理 -

//颜色渐变
public void SetColorGradient(Color FromColor, Color ToColor)

//颜色设置
public void SetColor(Color NowColor)

//随机颜色设置
public void SetColorRandom()

#endregion

#region - 文本转换为弹幕 -

//将指定弹幕中的字符拾取器中选择的字符逐字生成新弹幕
public void CharToComment(CharToCommentEditKind EditKind)

//将指定弹幕中的字符拾取器中选择的所有字符转化为一条新弹幕
public void CharListToComment()

#endregion

#region - 弹幕对齐 -

//左侧对齐
public void AlignLeftEdges()

//顶端对齐
public void AlignTopEdges()

//底端对齐
public void AlignBottomEdges()

//右侧对齐
public void AlignRightEdges()

#endregion

#region - 弹幕绘图 -

//设置基准点
public void SetLocationPoints(Point3D[] LocationPoints)

//设置旋转角
public void SetRotation(double RotationX, double RotationY, double RotationZ)

//中心旋转
public void SetCenterRotation(double RotationX, double RotationY, double RotationZ)

#endregion

后期的主要努力方向是绘图部分。

记得以前写过一篇以曲线排布弹幕的，已经快实现了w

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

最后贴张毕设的东西……

这就是传说中的苦逼蛋白质结构SAS表示法……

做死我了（死

我连自己都不理解我又会去理解谁
我连自己都不信任我又会去信任谁
我一直在等待着这两个问题的答案
虽然答案已然在我心中存在了很久

看了一下上次发的调查，居然全是用Win7的一刚！

当然还有各种Linux党什么的ww

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

今天做了好几件很有意义的事情呢w

首先万能的微博没有解决我的问题！异常处理这块我还是有疑问没有解决。

其次List这块折腾死我了，索性把所有不需要对List进行修改的参数全部改成了IEnumerable<T>接口。

再者尝试了ICTCLAS中文分词算法，觉得很有趣于是把这个模块添加到了弹幕设计器的模块里面。

比如将所有形容词予以放大的效果啦什么的ww

最后说最大的进步……三维基本几何变换。

写死爹了！

为了采用矩阵操作我还特意去弄了一个Math.Net库装上一刚！

其实像二维旋转那样直接写公式也不是不可以啦……

反正结局都是写死爹了总归要挑看上去帅气一点的方式你说对不

public static Point3D getRotatedPoint(Point3D CenterPoint, Point3D FromPoint, double RadiansX, double RadiansY, double RadiansZ)
{
    //Matrix Translate = Matrix.Create(new double[4, 4] { { 1, 0, 0, 0 }, { 0, 1, 0, 0 }, { 0, 0, 1, 0 }, { CenterPoint.X, CenterPoint.Y, CenterPoint.Z, 1 } });

    Matrix MCenterPoint = Matrix.Create(new double[4, 1] { { CenterPoint.X }, { CenterPoint.Y }, { CenterPoint.Z }, { 1 } });
    Matrix MFromPoint = Matrix.Create(new double[4, 1] { { FromPoint.X }, { FromPoint.Y }, { FromPoint.Z }, { 1 } });
    Matrix RotateX = Matrix.Create(new double[4, 4] { { 1, 0, 0, 0 }, { 0, Math.Cos(RadiansX), Math.Sin(RadiansX), 0 }, { 0, -Math.Sin(RadiansX), Math.Cos(RadiansX), 0 }, { 0, 0, 0, 1 } });
    Matrix RotateY = Matrix.Create(new double[4, 4] { { Math.Cos(RadiansY), 0, -Math.Sin(RadiansY), 0 }, { 0, 1, 0, 0 }, { Math.Sin(RadiansY), 0, Math.Cos(RadiansY), 0 }, { 0, 0, 0, 1 } });
    Matrix RotateZ = Matrix.Create(new double[4, 4] { { Math.Cos(RadiansZ), Math.Sin(RadiansZ), 0, 0 }, { -Math.Sin(RadiansZ), Math.Cos(RadiansZ), 0, 0 }, { 0, 0, 1, 0 }, { 0, 0, 0, 1 } });

    Matrix Result = MFromPoint – MCenterPoint;

    Result = RotateX * Result;
    Result = RotateY * Result;
    Result = RotateZ * Result;

    Result = Result + MCenterPoint;

    return new Point3D((int)Result[0, 0], (int)Result[1, 0], (int)Result[2, 0]);
}

如你所见，首先把FromPoint生成的矩阵由CenterPoint的位置变换到原点所对应的位置。

其次是轮流对XYZ三根轴进行旋转。

最后再将原点移回CenterPoint，并返回旋转后的点的位置。

而之前的那些Matrix都是定义的坐标和旋转矩阵。

好，最后我来说明，我为什么要写这个函数。

想到答案了吗？

这样的计算，是设计器第二版的核心内容。

但是，以上的图画，是还没有经过三维旋转的情况。

一旦对弹幕进行了旋转操作『X轴、Y轴、Z轴』，怎样确定一个字的基准点？

于是乎，刚才的公式就是进行这样的计算的。

getRotatedPoint(CenterPoint, FromPoint, RadiansX, RadiansY, RadiansZ)

第一个参数是CenterPoint，是指弹幕的基准点。在图上是(x0,y0,z0)

第二个参数是FromPoint，是指在旋转之前的，所要求的那个字的基准点的坐标。

第三到第五个参数，是指三根轴分别需要旋转的弧度。

最后函数得出的结果，是所求的字在旋转之后的坐标。

……

看不懂不要紧，下面是理论化的东西。

弹幕的精髓是“拆字”。

好，那么问题是，如何拆？拆到哪儿去？

于是刚才上面进行的计算就是告诉你，应该拆到什么位置去。

而设计器的核心在于“字变层”。

弹幕层决定了弹幕的属性，要改变属性则必须生成新的弹幕层。

撇开其他不谈，位置总是第一个要确定下来的吧？

『如何确定即将分离出来的弹幕层的基准点』，这就是一切的起因。

有人会说，我不用这种方法啊，我有最方便的方法。

保持想要分离的文字不变，其他文字全角用全角空白方格替换，半角用空格替换。

当然，这是很好的办法。

但是，也许播放器总有吃不住的那么一天。也许有些效果必须要以单字实现。

最终的结局不外乎是两种——

要么你花大量的时间去慢慢尝试，要么你使用数据运算。

我所做的，正是为了使后者成为可能。

最后有点小感想。

法兰西昨天说“于是以后不需要字幕君这个职业了……工业化时代到来”。我立马就想到了鸭梨之前也说过相似的观点。

这个时候我就很郁闷啊wwww

工具是为了什么而存在的？工具是为了辅助而存在的。

换言之，我并没听说过有了计算器就不用学数学、有了计算机就不用学写字的这样的论调。

人才是主旋律。

说来弹幕设计器的英文缩写叫做CAD『Comment Art Designer』。

而恰好CAD本身是『Computer Assisted Design』的缩写——计算机辅助设计。

所以，设计器的定位本身就是一个辅助，不会也不可能喧宾夺主。

的确，它能让量产变得更为容易。

但它的最终目的是，让弹幕君能够花更少的时间做重复的调校工作，而留出时间去构思崭新的想法。

所以，我希望最终有一天，我能填完这个大坑。

我也希望，各位弹幕君能够全面赶超11区的水准。

人家有SA我们没有，那我们就先把CA玩精了呗。

就这么简单。

其实我手头除了设计器之外还有两个很不错的中型项目没启动，果然还是对弹幕有爱呀。

有爱赛高，虽然自己明明就不是一个合格的弹幕君（笑

于是以上。米娜晚安/~

 Loading ...

我正在摇摆是不是要抛弃WindowsXP进化到Windows7，所以看看大家的使用情况。

忙着实习做数据库当小工毕设跟蛋白质球体战斗做这做那一直也没更新神马的。
忽然发觉一下子增员了……那就说一些最近的想法好了。
弹幕 = 弹幕属性 + 弹幕文本。
看上去真像是废话……

一、弹幕属性

1.基准点——弹幕的左上角的点的位置。
在经典弹幕模式『顶端渐隐、底端渐隐、滚动弹幕』中，这些模式所确定的是什么？确定的就是这个基准点。而2dland播放器中的网格，Bilibili播放器中的新弹幕XY坐标，都是为了确定这个基准点。

一旦确定了基准点，弹幕的基础位置就已经定下来了。

思考：这个基准点在两维平面内是XY坐标，今后有没有可能变成三维的？

2.时间轴——弹幕的出现时间、存在时间、消失时间。
所有的播放器都只有前两者，当然消失时间就是出现时间于存在时间之和，计算起来并不困难。为什么要加入消失时间呢？因为这样就方便控制一些效果（比如一同消失啦，线性消失啦等等）。

不过在这里消失时间并不是重点，重点是存在时间。原因在于，存在时间是控制弹幕层一切属性的线性变化的。同样是从基准点A移动到基准点B，不同的存在时间导致的结果就是不同的移动速度。

思考：滚动弹幕的移动公式是什么？

3.基本模式——顶端渐隐、底端渐隐、各种滚动
总结起来一共就两句话。
固定弹幕以模式、文本确定一个基准点。
移动弹幕以模式、文本、存在时间以及两个基准点确定速度。
然而反过来讲，有了基准点和存在时间，就已经能够确定模式了，文本居然不是必要的。
这就是我为什么在一开始就强调基准点和存在时间的原因。
更进一步的我会在接下来的文本区域的作用一节内说明。

4.其余属性——颜色、旋转角、透明度等等
这些东西从分析的角度就没什么好说的了，总之都是可变的属性。

二、弹幕文本

1.不可变性
弹幕文本相关的内容从弹幕出现之刻起不可变。
不过有一天我问阿伊特定字号的文字的长宽好像可以百分比缩放的，
这个其实也是挺好的一个可定制属性呢。

2.字体相关——字体、字体大小、字体效果
字体大小就不用说了吧。
然后弹幕字体以前大概都是黑体来着，然后现在的Bilibili貌似能改字体。
不过就弹幕制作者而言可能这不是什么好功能，因为字体的改变直接影响排版。
不过普通弹幕的话改改字体是不是也挺新鲜的（笑
字体颜色就是弹幕颜色，当然也可以把这个归进弹幕属性中去，没什么影响。
字体效果不多说，感兴趣的可以研究一下2dland的弹幕系统。

3.文本区域——弹幕文本所处的长方形区域
我也称之为『弹幕区域』。
决定弹幕区域的要素有两个：一是弹幕文本的行数；二是弹幕文本中最长的一行。
所有的弹幕文本在弹幕区域中左对齐。

4.文本区域的作用——属性不可定制的时代
如何定位？答案是霸屏。
经典弹幕还没有完全淘汰掉，不过这一天不远了。
把上面写的全部看完的人，还记得我刚才说的——什么是弹幕的基本模式么？
那么我再问一个问题，为什么它们会被称作“基本模式”？

那是因为“只需要弹幕文本相关的属性，就能通过基本模式得到固定的形态”。也就是说，并不是通过指定数据来确定位置，而是使用各种逻辑的组合来确定位置。所以，一旦要创造一个“模式”，就必须消减、固定或封装一切不必要的可定制属性。

关于这点我纠结了很久很久，最终的出的结论是——
首先要建立一个一切属性都可定制的原型，然后再以这个原型来实现现有的弹幕模式。这样的话，整个弹幕模式才能分离出层次结构的逻辑。不过很显然，Bilibili的新弹幕就不是一个模式。它是一个不完全的原型，而且这个原型正在朝着扭曲的方向发展。

我自己对于弹幕原型的设计做了很多次，包括双点定位啦，双状态啦等等，现在也还是不太满意。所以，这个肯定是今后的重点。感兴趣的详见最后的附录。

三、扩展主题

1.弹幕属性的线性变化
什么叫线性变化……这个我相信你们都懂的我就不解释了w在现有的弹幕播放器中，最明显的线性变化就是经典弹幕中的『滚动弹幕』了。于存在时间内，从屏幕的一边，移动到屏幕的另一边——这个是什么的线性变化？这个是弹幕基准点X坐标的线性变化。

毫无疑问今后线性变化将会更加广泛地应用在弹幕播放器的更新之中。譬如2dland的网格移动，Bilibili的新弹幕移动等等。同样不光是基准点，我想今后弹幕的其他属性也将会开放线性变化。

思考：还有哪些属性可以线性变化的？

2.弹幕属性的非线性变化
非线性变化还没有哪个弹幕播放器应用吧？我应该也Lag挺久的了w

刚才说了基准点的线性变化，我们来设计一个非线性变化的例子——弹幕以正弦波的形式运动。随便说一个好了，令一条弹幕的初始基准点为(x0,y0)，若有x=x0+t, y=y0+ASint，那么这条弹幕的移动轨迹就是个正弦波。

思考：如何让弹幕绕圆形移动一周？

讲到非线性变化有人就已经开始头疼了吧w不过这个受限于平台，在没有平台支持的情况下很难想象如何加入非线性变化。这个就要靠弹幕播放器的开发者们努力研究了。

3.固定与可定制到播放器能效谈
从2dland的/attr，到Bilibili的新弹幕，现在可以定制的属性正在越来越多。这是很不错的一件事情，因为我们可以通过它们实现更多的特效了。

然而想想看，为什么Acfun的经典弹幕只有三个模式呢？
……因为Niconico的播放器只有三个模式啊（揍
好吧为什么Niconico初期只有三个模式呢？
……因为没想到别的模式（口胡！

说正经的，最初的弹幕播放器，貌似就是简单地往MovieCanvas上画TextBox的感觉（现在还是这样吗？）。要知道，播放影片是一件让计算机很劳神的事情，何况这还是在Flash这个平台上面。在这个限制上，最初能够成型的模式，当然是要选择计算量小的方法了——简单来说，这样才“不卡”。细心的人会观察到，不同的弹幕播放器滚动的感觉都不尽相同，这就是实现滚动的方法不同所带来的，流畅与否的区别。

好吧由于本文是科普向的我就不往深里说了……总之，在没有经过更深层次的优化之前，弹幕播放器能够“不卡”并且实现的效果，直接限制了弹幕播放器的进化。同时，由于能效直接影响到用户体验，所以播放器的作者肯定是宁愿选择流畅，也不要华丽丽地卡死在某个点上。

说到这个，我倒是想到了某些人制作弹幕的方式啊www

思考：AS中还有哪些东西没有被挖掘出来？今后的弹幕播放器还会在Flash这个平台上吗？

四、结语
弹幕 = 语文 + 数学 + 物理 + 音乐 + 美术
看了这么多也差不多明白了为什么还要数学和物理了吧……
要成为优秀的弹幕制作者，缺一不可呀w

附录：弹幕原型设计

1.双点定位
这是我一开始使用的方法。
想要囊括滚动和固定，就直接以两个基准点初始化。
如果两个点的坐标相同，就变成固定弹幕了。
不同的话，则以弹幕的移动公式移动。

2.双状态
这是双点定位的进化型，也是我现在使用的方法。
弹幕的起始状态A有许多可变属性，颜色啦基准点啦角度啦等等；弹幕的终止状态B也有这些属性。
而从这条弹幕的生成开始，它要做的就是在一个存在时间内，把状态A的所有属性线性变化到状态B。
这个其实有点类似Bilibili的新弹幕，只不过更加可定制化一些罢了。

然而缺点也很明显——透明度这个东西，单向的线性变化其实并不好。从慢慢出现然后瞬间消失？忽然冒出来然后慢慢消失？两者都没有逐渐出现再逐渐消失来得亲切。所以在这点上，还是2dland的播放器拨得头筹。原因请出门右转弹幕测试专用w

3.多状态
多状态比双状态更进一步，是指在一个存在时间内，一条弹幕拥有多个状态。例如前30%的存活时间内透明度从0-255，中间40%的时间内维持255不变，最后30%的时间再从255-0。

虽然想法很好不过从设计到实现可能有点入不敷出，自己也会冒出“是不是有些做过头了”的感觉。
而且系统是否支持也是一个问题，总之作为理想化模型来设计就是了。