登峰造极者，殊途亦同归。

前言 本文章不包含代码分析，仅仅为使用手册。 ET本身就是一个很优秀的框架，对于ET的设计理念和核心思想，可以去阅读下原作者写的一系列文章：ETBook 这里也列举出一些学习资料，供大家参考 ET 6.0学习笔记——着重介绍ET6.0的新概念与设计思路 我的B站ET6.0视频教程——偏代码解读 字母哥Binary的B站ET6.0视频教程——偏实践 环境 服务器 .Net版本：.Net Core 5.0 云端服务器：CentOS 7.6 公共部分 基础架构 ET是一个单线程，多进程的框架，好处是单线程的开发效率更高，写出的代码更安全，Bug也更好查，多进程可以做分布式架构，均衡负载等。 ET框架采用了ECS架构（Entity-Component-System），而非传统的OOP架构，好处是开发效率非常高，并且借助于ECS的解耦功能，重构起来也很快。 但是ET的ECS也并非纯正的ECS，而是在架构学术派与实用派做了折衷，严格来说是E + S（Entity是纯数据，System是纯逻辑），那么把Component放哪了呢？在ET里Component就是Entity，Entity ...

前言 前几天给ET6.0写了一份FGUI代码生成插件，期间被一些容易混淆的变量名折磨的不轻，这篇文章就记录下从零开始的FGUI插件开发过程。 正文 环境 IDE：Rider 2020.3 Unity 2020.3.17f LTS EmmyLua 1.3.6.215 FGUI Plugin Lua API 首先下载FGUI-Editor，然后解压，定位到 FairyGUI-Editor/plugin/LuaAPI 目录，记住这个目录，我们后面需要用到他 安装EmmyLua插件 直接在Rider的应用市场下载安装即可 搭建插件开发环境 使用Rider随便新建一个项目，然后在这个项目里添加上面那个FGUI Plugin Lua API文件夹引用 然后再如法炮制，添加我们要开发的插件目录引用，比如 ET/FGUIProject/FGUI_ET/plugins/NKGCodeGenForET6 目前为止，我们插件的开发环境已经集成完毕了，并且得力于EmmyLua插件，我们还有了完善的Lua API提示（前提是在开发插件的过程中严格按照 EmmyLua官方推荐的注释方 ...

前言 由于之前已经写过很多ET相关教程，本篇文章主要提及ET6.0的新概念和新特性，其实6.0很多知识点和之前版本一样适用，想看ET之前版本教程的，可以前往：ET篇：个人笔记汇总 本文写作时对应的commit版本：https://github.com/egametang/ET/commit/43abb90cd05445f2e9a0625ac12caaab59486672 基础概念 此部分内容参考：ET6.0的设计思路 推荐大家有问题先去ET论坛逛逛，里面有很多管理员整理好的日常讨论答案，技术教程，以及其他朋友提出的问题，可以学到很多知识。 ET 6.0创新概览 之前每个功能是一个进程，比如realm gate location map，现在改成每个功能是一个Scene，一个Scene可以放到一个进程中。这样一台物理机先启动固定的进程，然后各个scene放到进程中运行。非常类似docker。 所有的Scene放在一个进程就变成了AllServer模式 服务器内部全部使用actor发送消息，比如realm发给gate，其实是发个actor消息到gate scene dbserve ...

前言 这阵子终于有空来整框架相关的内容了，目前处理到资源管理相关，自然还是选择我们的老朋友xAsset，简洁强大的资源管理框架！老版本的xAsset（4.0）我也写过一篇入门笔记，前阵子它发布了7.0版本 对比上一个开源版本（4.x），7.0 最大的变化是： 编辑器和运行时高度剥离，代码结构更精炼和模块化。 使用只读的物理文件数据进行版本管理，版本检测稳定性和效率得到前所未有的提高。 打包后的文件的文件名自带文件内容的版本信息，天生可以避免CDN缓存问题以及一些其他的冲突。 全新的多线程文件下载组件，真机环境比之前 UnityWebRequest 版本更稳定。 自动分帧机制为程序运行的流畅度提供保障。 加载资源默认支持自动更新。 相对详细的官方文档 今天就来学习下 正文 下载 xAsset地址，也是本文写作时的Commit版本：https://github.com/xasset/xasset/commit/69f04a06e4a900ce1f77f46e7a494fd19037c579 下载好之后直接将其中的Versions和Versions.Example放到项目根目录即 ...

前言 已经不止一次看到有文章说：不管有没有Early-Z最后的Late-Z一定会执行了，仔细想一下其实是不合理的： Early-Z相当于把Late-Z提前，一样会有逐片元的深度测试和深度写入，如果Early-Z和Late-Z是共存的，那么就有两次Z-Buffer的读取和写入，造成带宽浪费 Early-Z因为种种原因失效了，执行Late-Z无可非议，但如果Early-Z没有失效，我们都在Early-Z处理好了，为什么还需要在Late-Z处理一次？ 这篇文章就把深度缓冲区的所有操作都整理起来，并且还会包含一些引申出来的知识点，给每位看官进行一条龙服务。 正文 名词规范 国际惯例了属于是，为了避免歧义，本文中所有用到的名词，英语词汇都将在此处列出，希望看官们能把此处列出的名词和释义代入文章中，而不是自己脑海里的，这样你好我也好： PS：片元着色器 Z-Buffer：深度缓冲区 Z-Test：深度测试 Z-Write：深度写入 Early-Z：提前Z-Test和Z-Write，位于光栅化阶段之后，PS阶段之前，以pixel quad为单位（既以4个像素为一组，因为深度缓存内的数据 ...

前言 其实这篇文章的内容一直是在我的学习计划中的，但是由于种种事情而耽误了，最近正好有空，可以静下心来好好学习下，这篇文章应该是我2021年渲染学习的一个句号，剩下的一个季度要把精力放到技能编辑器的完善和状态帧同步的实现上。 学习对象依旧是Colin大神的仓库，这次的效果最为震撼和炫酷——基于GPU Instance的草地渲染 本文章主要涉及到的技术内容为： GPU Instance的底层原理 GPU Instance API 基于GPU Instance的草地渲染实现 草地渲染内容拓展 GPU Instance的底层原理 简单概括一句话就是：传递一个对象的Mesh，指定其绘制次数和材质，Unity就会为我们在GPU的统一/常量缓冲区开辟好必要的缓冲区，然后以我们指定的材质对Mesh进行我们指定次数的渲染，这样就可以达成一次Drawcall绘制海量对象的目的。 好处在于： 传统渲染方式（无合批情形）：绘制多少个对象就要整理和传递多少次数据，其中整理和传递数据的过程消耗极大，多数为性能瓶颈 GPU Instance：只用从CPU往GPU传递一次数据，大大提高了渲染效率。 ...

前言 花了两周时间，学习了Lua，并且基于XLua搭建了一套热更新框架，包括开发环境，XLua实践，基础建设（基于lua-protobuf的配置表和网络协议），OOP框架，UI框架等。这篇博客的主要内容也就是叙述这些功能的实现过程，包括过程中遇到的一些坑和解决方案，主要以讲述思路为主，其实也是我的学习路线和思路分享，希望对想着手学习XLua的同好有所帮助。 开发环境搭建 XLua下载 由于我们后面还需要接入lua-protobuf，RapidJson，LPeg，FFI for lua53等第三方库，所以推荐直接从 build_xlua_with_libs 下载最新的Release包，根据自己的需求选择目标Lua版本的Release包进行下载即可。 其中较为重要的是Plugins目录下动态库的配置，因为此处配置不正确会导致不同平台可能会遇到运行时找不到动态库的报错，官方的动态库和配置信息（动态库的mate文件）是直接可用的。 如果有自己编译动态库的需求，需要注意不同编译选项得到的动态库在Unity这边所需要的配置也不一样，对于第三方动态库的编译和p/Invoke相关的内容，可以前 ...

前言 要准备开始把状态帧同步方案接入Moba项目了，其中比较重要的两部分是战斗系统的重构以及技能编辑器的适配，前者先不谈，内容多而细碎，后面会单独出文章整理说明。技能编辑器目前使用了是基于节点的行为树编辑器，说实话对于技能的配置与效果的预览并不友好，但不可否认的是其逻辑组织能力雀食优秀，为了弥补其短板，准备接入一个Timeline编辑器，我的选择是ParadoxNotion-Slate，理由是界面美观，可拓展性较好，源码注释详细简洁。 这篇文章就是梳理下Slate的架构以及技能编辑器的适配思路。 Slate版本：2.0.2 正文 基础架构 由表及里主要有CutsceneGroup，CutsceneTrack，ActionClip三层结构，三者都实现IDirectable接口 CutsceneGroup：包含多个CutsceneTrack与多个Section，其中Section被用于划分CutsceneTrack区域和快捷编辑 CutsceneTrack：包含多个ActionClip ActionClip：一个具体的行为片段，例如播放一段动画，播放一个特效，移动一段距离 具体 ...

最近见识了一些人的行为方式，并反思了自己有无类似会让别人产生不适的行为，故有此戒文。 愿自己满腹经纶时，仍能谦以待人，温如君子。 愿自己有所长进时，能乐于分享，不苍白炫耀。 愿自己与人交谈时，能设身处地，善于倾听。 愿自己被人批评时，能抓住本质，不欲盖弥彰，固步自封。 愿自己愠怒难耐时，能保持清醒，不恶语伤人。 愿自己烦于生活时，能想到生活的美好，变得更加乐观向上。 愿自己烦于自己时，能正视自己，与自己和解。 愿自己半间不界时，能坚持不懈，努力达成目标。 愿自己短于他人时，能不吝赞美，互相进步。 愿自己走出半生时，归来仍是少年。

前言 马上要去上班了，这阵子雀食是啥都不想干，技能编辑器接Slate又费脑子，索性整点小活吧，想起来当前Moba项目的血条间隔还是用虚拟列表做的，性能捉急，准备用Shader重新实现一下。 正文 所谓血条间隔就是在血条中使用分割线来帮助玩家快速计算自身生命值的，个人认为是一个非常优秀的设计，比如下面的大塔姆，玩家可以在一秒钟之内就可以知道其还有360左右的生命值 因为血条间隔宽度和数量与战斗中英雄最大生命值有关，所以根据战斗中的英雄最大血量计算得出每个血条间隔的宽度值，传入Shader进行计算绘制，所以需要进行一些换算，现有以下条件 血条宽度为107px 英雄最大生命值为3700 血条每格代表100生命值 首先是血条间隔的数量，为 3700/100 = 37 个，而这37个间隔要均匀分布在107px中，所以每个间隔的宽度为100 / 37 = 2.70，注意，是100，不是107，因为我们绘制血条间隔与血条UI自身的宽度完全无关，根本原因是我们在Shader中会使用uv.x * 100的方式来构建一个虚拟的血条，所以不论英雄最大生命值是多少，都要除100。 123456Pe ...