游戏用到 C 代码的集成方案

[cloudwu]

最新的 commit 2aa9c48 增加了一个特性，生成一个代理用 lua54.dll 。这个东西曾经在 vaststars 项目里实现过一次，现在删掉了 ejoy/vaststars@ba5d512

动机

在开发游戏时，除非是一些小游戏，必不可少的会用一些 C/C++ 代码做扩展。对于 Ant Engine 来说，应该是扩展一个 Lua C Lib 。之前的问题是，Ant Engine 静态链接了 Lua 的实现。这是因为最初 Ant 是以手机游戏开发为主的，而 iOS 上只支持静态链接。

静态链接给扩展 Lua C 库带来了一些麻烦。如果额外静态或动态链接 Lua 的实现，是不正确的做法。

解决方法

所以，这次我实现了一个假的 lua54.dll 供 C 扩展链接。它和真的 lua54.dll 的区别是，内部没有 Lua 的实现代码，只是一个代理模块，但导出了所有的 Lua 5.4 的 C API 。

在引擎启动时，ant.window.start 阶段，会尝试查找同目录下是否有这样一个 lua54 的动态库，把进程内静态链接的 Lua 实现注入到这个动态库中。这样，运行时，动态链接这个库的其它 C 库就可以正常工作了。

如果需要在引擎外独立测试那些 C 扩展的话，也可以使用标准的 lua54 动态库。

使用方法

luamake lua54

可以生成 lua54.dll （或 lua54.so）这个动态库。运行时，它应和引擎主程序放在同一个目录下。而其它用 C/C++ 扩展的动态库可以动态链接它。这些库遵循和 Lua 官方推荐的一致标准，但需要在 ant.window.start 之后才可以 require 。

可以使用任何构建工具生成额外的扩展库，不必参与 Ant Engine 的构建流程。所以，可以直接下载已编译好的 Ant Engine 使用。但建议使用和 Ant Engine 一致的构建工具链：例如，使用 msvc 构建的引擎，也使用 msvc 构建扩展；如果引擎使用 mingw ，那么扩展也用 mingw 。debug 和 release 版可以混用。

和曾使用过的实现方案的区别

之前在 vaststars 项目中实现过一个类似的方案，但没有合并到引擎中。那个方案需要在引擎的 exe 中导出 API ，并在构建代理 lua54.dll 时指定 exe 的名字。

因为现在引擎会根据 exe 本身的名字决定启动在运行模式还是开发模式下，老方案不够灵活。

新方案采用更传统的实现方法，为每个 Lua C API 实现了一个桥接函数（通过代码生成的方式），并在运行时主动注入，而不是靠 os 加载动态库时自动加载符号。如有需要，可以在目前的代理动态库中做更多 profile 工作：比如统计在这个模块中的耗时等。

其它 C API

除了 Lua C API ，扩展模块可能还会用到其它 C API ，下面列出了可能的解决方案：

• bgfx : 在引擎的 Lua 代码中，可以用 local cinterface = require "bgfx".CINTERFACE 得到所有的 bgfx api 。它是 bgfx_get_interface() 返回的结构指针。把这个指针传给扩展库使用即可。
• luaecs : 它设计时就是 header only 的，所有 C api 都在 struct ecs_context 结构里面。通过 ecs.context() 就可以取到 struct ecs_context * 。