为什么有这个项目

[cloudwu]

动机

我的游戏项目不希望牵扯太多图形技术（分散精力），主要是实践 gameplay 方面的想法。策略向游戏目前用 2d 就够了，之前的 ANT 以 3d 为主，如果用来做 2d 游戏，多了许多不必要的复杂性。

另外，新项目不需要主打手机平台，不必围绕手机设备开发，所以 ANT 核心之一的 vfs 可以极大简化。直接使用本地文件系统能加快工作流。2d 游戏的美术资产制作简单（仅仅图片和非常有限数量的 shader ），也不需要复杂的资源编译过程。

我已经半年没有写复杂的程序，而写程序对我是一件非常有乐趣的事，开一个新坑会更有意思。

计划

我会从 ANT 中剥离一些已经证明有用的子模块加快开发。比如，ltask 可以方便 lua 多线程开发，所以是首选。

图形 api 打算尝试一下更轻量的 sokol 而不用 bgfx ，这是因为 sokol 只有几个 .h 文件，更容易集成，可以加快迭代过程。sokol 的 shader 方案更漂亮一些，对于 2d 游戏来说，只需要写几个简单的 shader 就够了，sokol 的 shader 方案用起来更简单快捷。顺便还可以使用 sokol 的窗口封装，这样就不需要自己额外再维护相关的代码。

当然，sokol 也有一些不如人意的地方。例如，不支持多线程调用图形 api 。在 bgfx 中却有完善的 encoder 解决方案。不过这点我已经想好了封装方法。

RmlUI 会是后续搬过来的模块，但需要先搞定图形层才能开始迁移。

2d 的图形层，即 sokol 的图形底层和上层游戏逻辑之间的部分，虽然比 3d 管线要简单的多，但也有一些有趣的东西值得做。比如上面提到的，如何实现多线程提交图形绘制请求（至少需要满足 UI 层的并行处理），如何尽可能的合并图形绘制指令，而不是每个矩形图元提交一次渲染……

计划可以在一个月内完成初步的工作，可以着手在此基础上开发游戏 demo 。

2d 图形层的设计

考虑到 2d 游戏中，绝大部分的需求是把一系列矩形图元绘制到画布上。除了画布整体缩放外，图元本身大多不涉及旋转和缩放，而只涉及它们绘制在画布上的位置。图形层最好针对这个特性来做设计。

图元包括图片和少量文字，暂先考虑图片。

为了简化开发工作流，图片在开发期间最好以通用格式保存在本地文件系统中。大部分情况下，需要有 alpha 通道（否则只就能绘制矩形了）
，png 文件格式是首选。解码 png 文件非常简单，速度也很快，所以不需要做额外的离线数据转换，直接在运行时解码就够了。

但直接使用 png 文件也有一些问题：

• 每个图元大小不一，异形尺寸的贴图对底层图形 api 来说非常不友好。
• 如果图元过多，还是需要考虑贴图压缩。毕竟压缩贴图的性能收益巨大。
• 生成序列帧动画时，往往把多张图片放在同一个 png 文件中管理起来会比较方便。
• 光有 png 文件往往是不够的，游戏使用时还需要一些额外的元信息：例如标准一个图片的绘制基准点在哪里（不一定是默认的左上角），应该截取图片文件中的哪个区域绘制（见上一条，序列帧动画）。

过去有很多游戏引擎的解决方案是把这些工作放在离线工作流里。常见的工作流程中有一步是图片打包。例如，TexturePacker 这个商业软件就专门做这个工作。通过把图片打包装箱，将这些图片资产转换为游戏运行时最适合的形式。

但我觉得现在的 PC 性能已经远超 2d 游戏的需求。分出一些性能来在运行时做这个工作，从而简化开发工作流会更有价值。开发工作流不仅适用于游戏开发者，也适用于玩家 mod 制作群体，这对独立游戏来说意义重大。

所以，我希望把图片装箱打包的工作都藏在运行时，对开发透明。甚至将来需要做图片压缩，也可以通过在本地建一个 cache ，通过比对图片的 hash ，在后台自动完成。

对于图形中间层来说，只需要一个这样结构的数据流：

struct draw_primitive {
	int32_t x;
	int32_t y;
	uint32_t sr;	// scale + rot
	int32_t sprite;
};

这个结构表示了需要怎样绘制一个图元。其中：

• x y 表示这个图元 绘制在画布上的坐标。它们由符号位和 23 + 8 bit 的定点数构成。
• sr 表示这个图元的缩放量和旋转量。当 sr == 0 时，表示保持原始尺寸且不旋转，这是一个默认值，大部分图元都使用它。当 sr !=0 时，分别为两个量 scale 和 rot ，其中 scale 使用 20 bit ，rot 使用 12 bit 。
  • scale 的高 8 位全为 1 时 ，表示图元需缩小到 (x & fff ) / 4096。
  • 否则 scale 是一个 12 + 8 bits 的定点数 x，即 x = scale / 256 ，图元需放大 x + 1 倍。注：最大数为 Binary 1111, 1110, 1111,1111,1111 即定点数 4079.996。最大放大倍数约为 4081 倍 。
  • rot 12 bit ，表示旋转角度为圆周的 x / 4096 。
  • 渲染底层会把 sr 转换为一个 float 2x2 的矩阵，sr 这个 uint32 值可以用作索引。
• 当 sprite 为正数时，它是一个图元的 id ，最大为 2^31 。渲染底层通过索引，可以找到它在贴图上的位置区域，计算出矩形的四个顶点的 uv 交给图形 api 。
• 当 sprite 为负数时，表示这是一个额外的材质，-sprite 为材质编号。而数据流的下一个单元（下 128bits，和 draw_primitive 结构等大）是额外的参数。例如，文本就可以是一个额外的材质，参数单元里有文本的 unicode 编码，颜色等信息。

若干 primitive 以及额外材质的参数单元组成的数组，称为一个 batch 。

struct draw_batch {
	int id;
	int n;
	struct draw_primitive * stream;
};

每个线程可以拥有多个 batch ，当 batch 准备好后，将 batch 指针提交到渲染线程。渲染线程则汇总所有线程的 batch 后，解析 batch 中的数据，翻译成图形 api 需要的数据流（通常是 vertex buffer 数据），执行渲染。

batch 的 api 是这样的：

struct draw_batch * batch_new(int size);
void batch_grab(struct draw_batch *);
int batch_release(struct draw_batch *);
int batch_busy(struct draw_batch *);
void batch_delete(struct draw_batch *);

业务线程通过 new 创建一个 batch ，然后调用 grab 再发送给渲染线程。渲染线程处理完毕后调用 release 表示处理完成。业务线程通常可以准备两个 batch 交替使用。当上一个 batch 提交后，下一帧开始检查 busy 状态，如果尚不可用（渲染线程还没有处理完上一帧），它可以用另一个 batch 组织数据。如果两个 batch 都 busy ，则等待。

渲染线程收集完当前帧的所有绘制图元后，可先进行当前帧所需的图片的装箱工作（组织贴图）。装箱结果可以 cache 到后续帧使用，也可以一开始预处理（如果整个游戏关卡的所有图片都可以全部加载到一张大贴图中）。这个过程比较类似虚拟贴图技术，即把整个场景渲染用到的所有贴图都组织在一起，而不是很多零碎的小贴图中。

对于默认材质，我计划用一个额外的 const buffer 在 gpu 中处理旋转和缩放变换。

默认材质只有一张大的贴图，所有图元都在这个贴图上。vertex buffer 中，每个图元都是一个矩形，也就是两个三角形（所以 index buffer 只有固定一个）。每组顶点数据只有位置（float 2）和 uv （short2) 以及一个 SR 索引（short) 。默认的 SR 索引为 0 ，表示不缩放也不旋转。

当 SR 索引不为 0 时，从额外的 const buffer 中索引 2x2 矩阵，乘到位置上。

渲染线程负责把 batch 中的数据查表翻译为 vectex buffer 和这个 const buffer （保存少量额外的矩阵）。

其它设计

虽然大部分代码用 Lua 完成，但我觉得把一些必要的 lua 代码直接放在 exe 文件中，发布时只有一个执行文件就可以用，这样比较酷。

我已经完成了部分，现在的项目编译后就可以单独运行，不需要任何多余的文件。当然，现在还没有开始做图形部分，只集成了 ltask 和 sokol app 。所谓多余的文件指 ltask 由 lua 实现的部分，我写了一个简单的 lua2c 脚本，把它变成 C 代码，link 在 exe 中。

btw, 目前从我自己开发方便考虑，使用了我最熟悉的 gnu make 做构建工具，只考虑了自用的 mingw 开发环境。不排除以后兼容其它平台和开发工具链（例如 vs）。

[xhacker5000]

我感觉做2D游戏最重要的就是一个UI编辑器，2d游戏就是UI拖拖拖拖拖拖

[RadiantFly]

但是UI编辑器这种东西，云风大佬不会去做的

[ebaecff]

期待

[gitByEOS]

这样精简数据还能支持形变么

[cloudwu]

多材质支持可以做到不同的 batch 用不同的 shader 。比如后面把 spine 数据放在独立的 batch 中。sokol 有已经实现好的 spine binding ，所以不需要额外实现了。

[tangyiyang]

有考虑在这个项目里引入ECS吗？想用这个来制作类似星际争霸的RTS游戏。

[cloudwu]

现在还没有计划，还在实现比较基本的东西。

[cloudwu]

https://blog.codingnow.com/2025/02/2d_pipeline_design.html 这两天工作的总结。

[RanhaoKang]

期待，非常喜欢小巧精美的项目，满满的掌控感

[actboy168]

强烈建议用 luamake 做构建工具

[waruqi]

禁用系统库就行了，走 add_requires("lua", {system = false}) 禁用系统库，就不会去走 pkgconf 这类从系统环境找库，完全从源码安装，然后直接从安装路径 ~/.xmake/packages/l/lua/v5.4.7/d033fb86e18647e0989bc9c724532e78/lib 取库。

然后完全根据 configs = {shared = false/shared} 去决定是否用 静态库还是动态库，跟 pkgconf 没有任何关系了。

[waruqi]

从这个意思上来说，我觉得应该是包本身去建议引用者使用动态链接还是静态链接。如果反过来引用者自己指定，因为不了解被引用包的实现细节，这样很容易出错。

不同的用户 需求都不同，就比如你这需要静态库，也有想要 动态库的，从包端建议，不可能满足所有场景，不管怎么建议，总是会有另一半的用户，提 issues 反馈为啥不是默认动态库，或者静态库，就像此处。

既然如此，还不如简单点，只需要所有用户记住一个规范。。默认静态库，可自行配置成动态库。。哪怕是一个项目引入上百个包，看一眼配置，也能几秒内知道，哪些包当前用的是静态库，哪些是动态库。

而不是挨个去猜，我当前的默认配置到底是用的啥。。

[waruqi]

另外，如果某个包 确实只支持 动态库，根本没有静态库，这种情况，也是可以在包配置中，强制默认动态库的。

https://github.com/xmake-io/xmake-repo/blob/f7e7fdc705550234a6c4b2b18b58fa405cbe24e3/packages/v/vc/xmake.lua#L10

这种情况，add_requires("xx") 引入后，用户端会有一个警告提示来引导，告诉用户你当前是在静态库配置下，还是用的动态库。然后建议用户显式切到动态库配置上去。

当然，如果你觉得还是想要 lua 默认走动态库，也可以按我上面的方式，重新定义下 lua 包，强制设置为默认动态库，就行了。

所有包都是可以在用户侧改写的。。官方仓库默认一般都是按现有的规范配置的。

[actboy168]

soluna 用 submodule 的方式引用了 lua std 等第三方库。所以构建脚本必然是需要使用 submodule 里的代码来构建，而不是另外再引用其他的代码来构建。

[waruqi]

这个随意，我只是提供个 example ，具体是否用 submodule 按个人项目 自己决定，没说一定要用 package，走 submodules，直接追加几个 add_files 就完事了

[julywind168]

为啥不先做个编程语言呢（既可编译到本机，也可以解释运行），这样 引擎和 gameplay 可以是同一种现代语言（引擎编译到本机提高性能, gameplay 开发者可以选择解释执行方便更新）。也能避免 Lua 动态类型的缺陷。🤔

[cloudwu]

我不喜欢 godot 的最大原因就是 GDscript

[linkliu]

没有用过GDScript，现在Godot都是直接C#开撸。

[samoyedsun]

支持发布成H5吗

[cloudwu]

H5 不在我眼下的需求里，我不会把发布 H5 这件事放在当前的计划中。不过 sokol 的图形 api 层是为 H5 设计过的，所以我认为只要想做的时候，就可以做。

[vkensou]

struct draw_primitive {
	int32_t x;
	int32_t y;
	uint32_t sr;	// scale + rot
	int32_t sprite;
};

参数sr我建议还是展开为float s, float r。你上面提到的规则太复杂了，记不住。底层自己打包转换好就行。

[cloudwu]

所有 C 结构都是给底层用的，代码随时调整。这个转换是在 inline 函数中完成。

[vkensou]

建议参考这个接口，一步到位
https://love2d.org/wiki/love.graphics.draw

[vkensou]

没有用ANT太遗憾了。2D渲染这一部分完全可以做成一个模块嘛。

[cupen]

用 ts 取代 lua 行不。

[xiaoliang6669]

claude 4出来了代码能力非常强，建议借助AI魔改godot4，2d游戏领域godot4受众最多,对业余选手最友好AI可控性也最强，ai直接写场景文件出界面ui，做游戏纯鲁代码的时代过去了。

[moloxiao]

现在大家一般怎么搞？GoDot用AI感觉没有前端那么方便