自从19年疫情开始有意识的关注消费主义,最近又看到一个宝藏视频。里面的观点其实跟之前一部分有重合:拒绝消费主义强加到消费品的符号。不过还提出了一个更加有意义的观点:不要消费自己想要的,消费自己需要。里面提到一个需求清单,在下面摘录出来了。我觉得很多人(包括我自己在内)被消费主义麻痹了。过多的关注消费带来的符号,而不是自己基础的需求。
-
威联通NAS(QNAS)的DDNS域名在国内部分地区解析失败以及解决办法
大概在半年前,发现手机的Joplin无法同步QNAS中的笔记。一顿排查后居然是5G的网络用的DNS服务器202.96.128.166和202.96.128.86这两个解析*.myqnapcloud.com失败,全部返回127.0.0.1,详情看这里。
保障到中国电信,反馈该域名没有在白名单中,需要域名的拥有者申请。遂联络QNAP的HelpDesk,客服反馈很积极,但是由于这个只有部分地区有问题,而且他们也不清楚电信那边具体要做什么。他只能建议我用中国区的域名,问题是最近中国区的域名也不是很稳定,解析从myqnapcloud.cn切换到mycloudnas.com了。最后只能放弃。
直到今天看到cloudlink的app更新了,看了一眼CL,其中有一条:
Added support for adding 3 DDNS alias names using mycloudnas.com.
是不是全球的也可以用mycloudnas.com这个域名了?加了一下别名,还真的生效了,而且电信也能正确解析了,而且let’s encrypt 的证书也支持两个别名,困扰半年的问题终于解决了。PS:反代也需要重新更新一下证书(重启就行)。
-
关于国内新能源发展的一些想法
最近看到B站有财经区UP主在讲《2024—2025年节能降碳行动方案》
- 大势不可逆,燃油车退出历史舞台的步伐会加快。不负责任的说,燃油车还有15-20年的寿命,然后逐步推出历史舞台,加入到博物馆行列。
- 电车用电成本低也随着燃油车退出舞台成为过去。以后公路的费用会由电车一起承担。
- 强迫生产端更新,取代化石燃料,工业用电需求会增加。电价肯定会涨,居民端应该不会有太激烈的调整幅度。生产端估计会成本增加不少。虽然不是直接传过来,但是物价涨估计在所难免。
- 用电的话,蓄能是一个大问题。对于农村地大,有条件自己建设蓄能设备,可以减少价差。现在的蓄能都是国家在搞,利用水利。城市的话各家各户自行建设蓄能不现实。那城市的蓄能会怎么发展呢?有没可能会统一在城市建蓄能站,然后由市场驱动低价电的买卖,形成市场化呢?这个是有可能的,另外还需要考虑峰谷电价差,只有足够大才有利润;另外蓄能的效率也是很讲究的,化学蓄能达不到水利蓄能的效率。
-
中文的WordPress博客回来了!
感谢阿里云的99计划,本来想试试阿里云的,但是发现要重新备案才能。现在阿里云备案(广东)要签承诺书,还要打手印,简直就像卖身。虽然我自己没什么不见得人的,但是就是不爽。还好腾讯也被卷起来了,99/年的轻量云还可以。带宽大一点,但是限流量(300G/月)还行吧。
主机拿到手后本来想搭的dokuwiki做分享的,但是搜着搜着找到我以前在V2的一句留言:”wiki 是给大家一起编辑用的,不是给大家看的;要给大家看的,CMS 了解一下”
对啊,既然我只是想整块分享内容,没有共享编辑的需求,为什么要用wiki呢?所以另辟蹊径,找到了Obsidian+Squartz的方案。跟jekyll类似,本质也是SSG。但是由于有Obsidian的Backlink加持,分享会更加成体系。目前的规划大概是Blog、数字花园(DigitalGarden)、首页。更新频率从高到低、内容质量从低到高这么一个规划。
或许这里以后会变成一个高频率、吐槽、低容量的地方。但总比荒凉之地要好吧?
Update:
-
GODOT引擎中的一些概念
Server
- 一个引擎内部代码组织代码概念,主要用途是用来将引擎内部一些比较独立系统组织起来。
- 只是一个逻辑概念,代码上没有一个框架,都是每个Server按照自己的情况去创建。
- 嵌入到引擎也是通过Hardcode(例如在main.cpp初始化某些Server)
- 一般来说每个Server都是有自己一套线程运行,跟主逻辑线程主要依赖CommandQueue(引擎提供),主线程一般只在需要的跟Server做同步(例如物理、渲染)
- Server本身是一个Object,可以发送信号到场景对象。
Modules和GDExtensions
- 两者都是C++扩展引擎的方式,主要区别是Modules是以静态方式编译进引擎,GDExtensions是动态库方式。
- Modules功能更全,因为和引擎一起编译,可以访问所有的API。不过官方承诺如果发现GDExtensions实现不了的功能,可以提Ticket,尽量保证和Modules功能相近。
- GDExtensions编译更快,Modules修改需要重新编译整个引擎(但是我觉得只要依赖正确,基本多不了多少时间)
- GDExtensions由于是二进制,可以使用其他语言开发(社区有个Rust的)。大概只需要将引擎的API导出到Rust就可以(不过引擎API的二进制兼容性如何?)
- iOS不支持动态库加载,GDExtensions似乎无法使用,也没法直接将GDExtensions静态连接到ios。
参考:
-
HybridCLR浅析
周日心血来潮开了一下Unity,突然想起之前有一个据说秒天秒地秒空气的热更框架huatuo,打算找来研究一下原理。
搜索了一下,发现huatuo已经归给掌趣,作者后来自己开了一个HybridCLR。知乎、B站、Google搜了一圈,发现基本都是同样的内容,像极公关稿。说什么工作在IL2CPP层、没有虚拟机、性能牛B、开箱即用,玄乎到不行。好奇行心驱使下,看了一下源代码,大概明白工作原理:
- 在IL2CPP生成完Unity自身C#对应的C++代码之后,插入一些HybridCLR的C++代码,其中包含所谓的interpreter和transform。
- interpreter本质就是一个虚拟机,用来执行
HiOpcode
。 - transform就是用来做IL->HiOpCode转译
- interpreter传宣是register based,但是代码看来就是stack based。不知道作者是否有商业版本的实现
- HiOpCode就是基于Unity的一个特化指令集。只要指令集命中的执行效率肯定高,除此之外通用性能可见的不太理想。另外虚拟机的指令集是变长的,想要优化效率估计有困难。可以简单类比CISC和RISC的区别。
- 相比现有脚本解决方案,绕一层C#再到引擎接口,HybridCLR直接通过interpreter调用IL2CPP::vm接口,确实性能会有优势。还是那个前提,只要你的代码能命中特化的opcode。
- 这个方案的本质还是Unity不提供纯C++库的调用方式。IL2CPP::vm这个胶水层虽然比直接C#要薄,但是相对纯C++接口还是太厚了。如果Unity自己能提供一层C/C++的封装(类似fmod那样),对脚本接入就不用这么纠结。
综上所述,HybridCLR所获得的性能提升主要在更薄的胶水层和特化的OpCode;相对应的通用解析性能可以预见的不高(盲猜,没有任何证据,不用杠。杠就是你对)。对于纯C#的项目,想获得一些热更修复的能力,可以考虑。如果是想达项目的脚本化,HybridCLR估计有难度。
ILRuntime的原理其实也类似,只是我记得最早ILRuntime是直接运行IL OpCode的。今天看了,好像也用了类似的方式。
-
入了一台官翻的Macbook pro M1
最近把老婆的以前剩下的那台小米笔记本Air给了出去,就有理由重新买一台笔记本了。自我上一台Macbook pro 到现在估计已经有10年了吧。说来也巧,那台笔记本也是官翻的,从香港官网入手的。还记得到了之后的那天,激动的请了一天假,当天就去香港提回来。
说回这台M1笔记本,是直接从大陆的官网下单的,多了消费税,比之前的从香港官网自提稍微贵了一点。配置选了32G + 512 的14寸8核的配置。总体感觉这个配置对我来说性价比是最高的。14寸刚好有XDR屏幕,32G内存也够用。因为macbook的内存不可以扩展,只能一步到位。512G硬盘相对勉强,但是我觉得差价1.5k的差价,够买个2TSSD扩展了。而且macbook还可以插SD卡,硬盘应该够用。处理器8核和10核的数据,纸面的数据是强了20%,但综合考虑了一下续航、实际的提升以及自身需求,8核的性价比会更高。图形核心更不用说了,我要图形性能不考虑台式机?
曾经有考虑过,够买一些轻薄本(XPS之类的)或者游戏本(R9000K之类的)。游戏本那个重量和体积真的劝退;轻薄本的话,确实还可以。但是续航始终还是Mac更占优势,而且价格也没比Macbook便宜多少。
其实从官网的货源来看,这款配置的缺货程度也是最高的,可见也是比较受欢迎。可惜没在M2 Macbook出来的时候快速反应,不然还可以去购买员工优惠,还能更便宜1.5K左右。目前来看这个Macbook Pro算是不错的选择。希望之后能再陪我下个10年吧LOL。
-
Cocos2D-X历史回顾
今晚在整理以前的笔记,发现一篇关于cocos2dx renderer的设计摘录。cocos2dx可以说是我客户端之路的启蒙引擎,对我有很大的启发,也跟随着我经历过一段神奇的工作经历。好奇心驱使下,去搜了一下目前的状况。发现2018年基本已经停止更新,最新的版本也停留在v4.0(2019年)。后来的替代者是cocos-engine。简单的浏览了一下文档,虽然增加了不少新的特性,绑定语言也变成了TS,从代码树来看似乎也继承了cocos2dx部分代码。但是整体的功能和设计不要说跟双U比,就算跟目前的后起之秀GODOT也差了不少,论坛也比较冷清。
这不禁使我思考,为什么当时如日中天的coco,为什么后来会掉队呢?
崛起
cocos2dx其实是从coco2d的’翻译’过来的(我记得后面甚至原作者也跳到cocos2d)。coco2d是一个基于ios objc的2D引擎,一开始定位就是做2D小游戏的。在这样的背景下,再加上钓鱼达人在手游的爆火,作为幕后功臣的cocos2dx自然得到更多人的关注,而当时正处于手游崛起时代,国内(国外)游戏引擎近乎空白。cocos2dx自然顺利成章的’补位’。
转折
对于cocos2d-x v2.2之前的历史我所知不多,但对于v2.2以后甚至v3.0的版本,可以说这个引擎的巅峰,时间大概是2012-2015年。伴随着各大传统厂商入局手游,市场迅速扩大。cocos2d-x可以当时游戏研发的唯一选择,当时的触控科技可以说是当红炸子鸡。触控当时也看到移动设备的性能不断攀升,推出了重构了渲染层、’支持’3D的v3版本。在我看来,正是这个风向的转变,让cocos2d-x从第一梯队掉队。我认为主要原因:
- 兼容性。V3当时的定位是V2的迭代,迭代了渲染队列和增加能显示3D的节点Node3D(如果我没记错的话?)这就导致花了大量时间的V3实际只是一个能显示3D模型的准2.5D引擎。从现在我个人的角度来看,如果要做3D的话,原有的引擎API根本不适合,单说场景管理这块就已经很头疼。另外3D引擎的工作流需要有很强的定义和整合能力,当时cocos2d-x也是一个渲染引擎,根本达不到这样的高度。与其从V2兼容迭代,不如另开炉灶,做一个领先时代的新的产品。事实上触控后面也开了Cocos Creator,UE3->UE4也是完全重写(虽然用了不少UE3的代码)。
- 稳定性。对当时cocos ui 编辑器的稳定性印象深刻。每天都会crash不少次,还会有一些性能问题。即便是后面的版本也基本没有太多改善。对于inhouse的工具,可以忍;作为一个产品几乎无法接受。
- 技术滞后性。cocos2dx很长一段时间都是以一个单独的渲染引擎+UI编辑器存在。直到后面Unity出来,才发现可以将所有东西整合在一起作为一个编辑器。这时候Unity已经以技术领先态势抢占市场份额。回头Unity在3D引擎的基础上开发出2D引擎的内容把cocos2d-x仅有的2D市场也吃掉。
总结
其实,无论你之前处于什么样的领导地位,只要一次没跟上时代的步伐、看清楚形势就会被时代抛弃。无论是对于个人或公司,触控如是,诺基亚如是。反观同样是有自己产品和引擎的E宝,在Unity已经抢占手游市场的大半江山,依然能通过开源占领市场,并利用自己技术优势和不断迭代,重夺引擎市场桂冠。可惜,触控始终不是Epic,时代总要翻篇。