我最近在写关于 GRIS 的文章。由于种种原因，现在进度只有大约三分之一，所以更新要等到之后了。不过我尽量赶在时间节点之前写完。为什么要写，简单说来，就是冲击太大了，“余音绕梁，三日不绝”。回头再看一些我所知道的玩意儿，瞬间就觉得索然无味。

如果有人关注我最近的活动的话或许会注意到，这半年来我推代码的频次相较以往同期要少。嗯，首先是 CS 确实很有意思，而且以我的基础可以看得比较全面（能自然地看见“点”之间的“线”），这样要深挖的就多多了。HTI……我的思维运转方式不是那样的，所以除了课上讲的冰山一角，基本都看不清，所以业余时间都投入到代码上了。

还有一个原因是我希望做一个更有趣的人。除了抽象的代码，我也乐于欣赏艺术创作。欣赏久了，自然就产生了投身于创作的想法。就像笼中之鸟羡慕飞翔的鸟儿一样。以我的性格，要是只能代码一条路走到黑我肯定要抹脖子了。

在B站上我一般是做烧笋的创作谱面。这是我放松的一个选择。但是这毕竟形式非常单一而且（我认为）总是摆脱不了无生命感。——写谱面，在许许多多的规则之下，发挥的余地其实比较少（我不是硬核玩家），而且普遍关注的是技术难度，缺少要表达的主题。每一种艺术都不过是表达的方式，私以为代码也是这么一种手段；有的人擅长这种，有的人擅长那种，仅此而已。当然观众也得有相应的鉴赏能力。

所以我就想了，要是投入等量的时间，能让一种技能从70上升到75，或者让另一种从0上升到15，该如何选择呢？事实上这和 RPG 游戏加点一样是个一直困扰着我的难题。我选择在艺术上从0加到15，很清楚这并不会带来“一技傍身”的优势，而是希望借由将自身化为艺术创作者，去理解他们的视角和思维，会遇到什么问题，我的方案比别人差在哪里或者好在哪里。

继最开始的简单剪辑（1、2）之后，我开始尝试其他的形式：混搭（1、2）、手书（1、2）、MAD 和改谱（远算不上编曲）。每个作品的个中滋味恐怕都不是一两段话能说完的，也并不只是视频简介里的那些。当然，创作水平肯定是无法一蹴而就的。所以除了我自己的练习和体悟之外，我希望寻找更新的想法，希望它们也确实地传达给观众了。反正又不图名又不图利，若是能被欣赏，或进一步地，在此基础上衍生创作，丰富大环境，那就是更好的了。

那么近况如何呢？我确实在大脑没退化的前提下比之前更快乐了。比之前整天在代码上挖掘，望天叹气要好多了。我觉得这偶尔的音乐、绘画和视频创作是有一份功劳的。自己有趣不有趣……还不知道。至于产出的效益，那要等时间来回答。

胡乱说了一些话，权当跨（农历）年的一篇吧。

NW.js 有一个或两个上下文，使用时要多加小心。

查看更多

以前我写过钢壳都市雷吉欧斯中的告白台词。今天我又看到了一出打动人的浪漫戏，《老虎和兔子》（Tiger and Bunny）第15集。嗯，这集本身是一个插曲，但也是主线剧情的关键转折点之一。

注意：本文有（严重）剧透。

查看更多

中文版本见这里。

Recently CRI Middleware updated their latest ACB archives’ format, and they seemed to have updated encryption of HCA files as well. As a result, the old toolsets can do nothing on the updated files. After about 20 hours of research I finally found what they changed on the decryption. Might be the first in the world, again. This is what’s called “highlight moment” in reverse engineering. XD

The final answer is somewhat simple: transform the decryption key, and use the transformed key to initialize the decryption table. The formula is key' = key * ((uint64_t)(k2 << 16) | (uint16_t)(~k2 + 2)) where key is the input key and k2 is a secondary key stored in the higher 16 bits of “field alignment” field, in each ACB/AWB file.

This article is about the way and thoughts of finding this transformation. It is roughly recorded in time order. I hope this materials may help someone in the future.

My result is based on various people’s works. Without thoses pieces, the whole puzzle cannot be completed. So a big thank you for everyone involved.

Be noted again: the contents in this article must not be used for commercial purposes.

查看更多

English version can be found here.

近日 CRI ACB 格式更新，连带着 HCA 加密“升级”，旧轮子全员阵亡。在经过二十多个小时的研究后，我找到了关键的修改，搞定了解密。可能又是全球第一个呢。做反向，最激动人心的就是这样的时刻。XD

最终的答案很简单，就是在解密之前，进行密钥变换，并二次初始化解密表：key' = key * ((uint64_t)(k2 << 16) | (uint16_t)(~k2 + 2))，其中 k2 保存在每个 AWB 中的字段对齐的值的高16位。

这篇文章讲的是我找出这个变换的过程，包括思路和操作，基本上按照时间顺序记录。希望在未来会对某人有所帮助。

总的来说，这次的成果是建立在众人的工作基础上，没有这些碎片，就无法拼成完整的拼图。在此要向各位致谢。

再次强调，本文内容不可用于商业用途。

查看更多

今天花了两个小时，将 Icarus 主题更新到最新，同时保留了一些我自己的修改。所以现在的界面会和原来的略有区别。猛然发现，直到更新之前，我用的还是2015年时的主题，只不过自己进行了一些微调和功能更新。当初刚开这个静态博客的时候换过几次主题，最后考虑到自己的使用场景选择了 Icarus。

关于《心跳文学部》（Doki Doki Literature Club）。毛二力

网上各种评价、剧情解析、心得实在是数不胜数。所以本文就不写那些无聊的东西了。这是个元游戏（metagame），Monika 你不是喜欢meta吗，那我就来meta你。我才不会像普通玩家一样甜（甘い，天真，naïve），傻乎乎地跟着游戏系统走。

本文含有剧透。如果介意，请至少先通关“普通”结局。

警告：《心跳文学部》含有令人不安的、冲击性的内容，不适合儿童和容易受到刺激的玩家。

查看更多

因为这7个月（或许可以说是一年多）以来的种种事情，虽然有一些破碎的文字，但是没有写文章的动力，所以博客更新断了很多。雪球滚到后面，甚至都不想再打开来写了。

到现在情况稳定了一些。所以决定继续更新，并尽量将之前只有些许句子的东西写完。发布时间将仍然按照记录的时间，所以可能之后见到的一些更新是来自今年二月、三月等等的文章，首页可能就没太大的变化。还是 RSS 好啊。

今天在北京遇见的三件事。从中大概能瞥见一丝市井百态。

查看更多

系列目录

* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）

这篇文章讲一下土豆的物理。物理我没完全做好，但是至少做到了可以接受的程度。一些改进的想法我放到了代码注释中，有兴趣的人可以尝试实现一下。

查看更多

系列目录

* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）

这篇文章里，我讲一下土豆的面部操控（表情和口型）。

查看更多

系列目录

* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）

这篇文章讲解土豆的摄像机数据。

10月更新：近日在测试玩具的时候，发现 Unity 是直接支持 F-Curve 的（见 KeyFrame 的文档），而且其构造函数已经清楚地说明了值的意义。是我孤陋寡闻了。

查看更多

系列目录

* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）

有了前两篇文章打下的基础，终于到了最重要的一个部分，就是动作数据在两套骨骼之间的变换。

这里要特别感谢丧丝，他在转换烧笋（CGSS）到 PES（实况足球）的时候想出了这个方法的大概，不过“还是很模糊，不知道是怎么做出来的”。我不过是将其证明了而已。方法的核心也是非常之简单。

后面讲土豆骨骼和 MMD 骨骼的异同，以及如何（与 TDA 式）做到较好的兼容。这部分其实不看也行，如果你比较熟悉 MMD 的话。比如标准 T-pose 变换为其他样式的初始姿态（比如 TDA 的±34°），这一步也可以通过 PMX Editor 搞定，不过我还是想程序一步到位。反正我不熟，所以大致地讲一些经验，能有原理就最好。

对了，还有 IK。

查看更多

系列目录

* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）

在这篇文章里，我讲一下土豆的身体动作数据。

查看更多

系列目录

* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）

在这篇文章里，我讲一下土豆的模型网格（mesh）和骨骼（skeleton）。虽然贴图是我后来才加上去的，不过考虑到叙述顺序，还是放到这里一起讲。

查看更多

* “土豆”指的是偶像大师百万现场剧场时光（ミリシタ/MLTD）

最近做了一点微小的工作，提取了土豆的模型和动作，并（可选地）转换到了 MMD 系的格式。为什么是 MMD 呢？虽然它的功能十分简陋，但是毕竟是当今最大的爱好者所使用的、较为开放的平台。

下面这个系列文章的目录。

• 一：模型和骨骼
• 二、身体动作
• 三、土豆与 MMD 动画信息的兼容
• 四、摄像机
• 五、表情和口型
• 六、物理（不完全）

以后可能做（做了以后找时间写）也可能鸽的：

• 七、高级 shader
• 八、场景

代码位于 GitHub。

我肯定不是第一个完成这事儿的人，因为早就有列表了。上面标称是“トレス”（trace，临摹），但那精度怎么看都像是直接提取的。还有，我前几天玩 VRChat 的时候，就发现有人把土豆的剧场都做进去了：入口、几个房间、舞台（甚至还有一周年的舞台！），一些模型（能看到有bba的限定泳装，说明是不久前弄的)。在游戏中搜索“iDOLM@STER”就能找到。因此我推测有一个十分便捷的工具或者方法，能将 asset bundle 里的模型整体地提取出来或者以其他方式使用，但是我还不知道。我没去 XeNTaX 看过，不过那地方高手云集，应该也有人做了。

我已经将工具公布了。我并不会像某位仁兄一样拿着别人的成果到国内某视频站上不加来源（我开始还以为是他自己完成的，结果我还没问他就自己爆料了还行），吊人胃口，然后在私人群里二次配布（无论有没有获得初次提取者的授权）。以上属于二级信源，并没有完全确认。我写这个系列有两个目的，一个是科普，另一个就是狠狠打脸。这些数据的版权万代肯定是不会下放的。所以各位也自己注意点。

相关测试视频：

• 花ざかりWeekend✿ 动作测试：验证提取的模型网格（白模）和身体动作数据
• Blooming Star 动作测试：测试转换模型和动作到 MMD 体系
• Blooming Star 动作/镜头测试：测试转换镜头到 MMD 体系
• 気まぐれメルシー IK 测试：测试自动生成 IK 骨，让 MLTD 模型可以使用一般的给 MMD 制作的动作
• 気まぐれメルシー 动作修正：修正 T-pose 差异
• 気まぐれメルシー 面部表情测试：测试转换模型包含的表情和口型模板到 MMD 体系
• Blooming Star 表情/口型测试：测试播放提取自 MLTD 的表情和口型数据
• Blooming Star 物理测试：测试根据 MLTD 的物理数据自动生成的 MMD 物理
• 自分REST@RT 综合测试：测试以上的各项在 MLTD 多人场景下的表现

《超能力女儿》（ひなまつり）的ED，《鮭とイクラと893と娘》。附带一些科普和私货。

查看更多

想象一下你能选择无限多条路，每一条都有无限多的岔路，但是主干道之间并不相交。所以一旦你选择了一条，比如说去多伦多的路，你仍然有无限多的选择，不过它们之中没有一条会通往芝加哥。

应该是好几个月之前了，MLTD 用了新的加密额外的混淆和保护（AppGuard；不过仍然被大佬脱壳了），这次会检测程序完整性。因此之前取密钥的方式（中间人）就不能用了。可能以后真得要去hook系统 API，dlopen 什么的，或者自建沙箱。

关于它的网络部分，我已经没精力去做了。对我来说，双线作战，还要还原 D2D1，还有 Vanishing，工作量已经不小。还有一些内部因素。应该不会像以前那样能用整个晚上来跟踪和分析 ARM 汇编了。仔细想想开的项目全是个人项目，而且有些相当硬核，开得越多战线越长，渐渐就被拖垮了。啊好像草菇的网络也好久没去维护了。总之已经退出了第一线数月。

然而我的兴趣不是在查询和计分上。我又不打分，别人打不打我无所谓。而且就为了在游戏中打出高分的假需求，集成现有的 API，这种活儿太无聊了。一般用户希望拿到的是一个好用的工具，比如app，这对于他们来说是最容易理解和使用的。不过我是想去开辟可能性的，开发用户应用的就踩着我的肩膀前进吧。哦对还有，我大概是老古董了，对智能手机有着本能的抗拒。

MilliSim 其实也逐渐成在往通用引擎上走，就跟 osu Framework 那样。但是我在尽量解耦，也一直在想 MilliSim 的意义是什么。从一开始对谱面的系统感兴趣，做来做去发现也就是那么一回事；现在逐渐又想看小姐姐跳舞了，而且就算是音游也会有相应的 BGA；于是又在想我为什么想看小姐姐跳舞，音游这个载体（是音游，自然前景要有谱面，和背景是什么关系呢）对我来说是不是过时了。这样下去会成艺术指导吗？变来变去什么时候是个头呢？

可笑，虽然能把计算机系统看得很清楚，但是对未来和目标（假如是唯一的话）却根本看不见。

这篇文章本来想复用以前的 FFmpeg+SDL2 以及 FFmpeg+OpenAL 两篇。但是所用的语言不同，所以设计有差异；FFmpeg 的 API 更新（用的是3.4，当前最新的版本）也要求使用新的 send/receive 解码模型。这次的代码是从零开始一步一步写的，比起以前没搞懂，凭着模糊的直觉复制粘贴去做的那两篇，算是有所长进。我终于敢说，整个流程弄清楚了。

这个工程的考虑就不只是网上的那些“简单的播放器”的那么一点了，我本来也没想把它做得多“简单”，只是写得尽量简明。目标是一个成熟、稳定的库，就得十分注意正确性、鲁棒性和效率。编写过程中也碰到了一些困难，所幸都解决了。

文章分为六个部分。第一部分讲基本概念；第二部分讲视音频解码；第三部分讲同步控制；第四部分讲解码输出；第五部分讲工程中用到的一些细节的设计思路；最后一个部分讲一些对比和想法和现状讨论。（原本放在首页的大段文字都放在了文章最后部分，不想让“摘要”看起来太乱。）

代码位于 GitHub。

查看更多