【免费下载链接】sbox-publicsbox is a modern game engine, built on Valves Source 2 and the latest .NET technology, it provides a modern intuitive editor for creating games项目地址https://gitcode.com/gh_mirrors/sbo/sbox-public点击查看免费下载sbox 引擎使用engine/Tools/InteropGen工具从.def文件生成 C↔C# 双向互操作绑定代码。本文以 .def 文件格式文档 为主体逐条讲解文件语法、顶层指令、include / inherit / skipall 组合机制与 manifest 清单并结合仓库内真实 def 文件如 engine.def、tools.def与 GlobalParser.cs 源码让你完整掌握如何阅读、编写与组织 binding set并理解绑定集之间如何复用与排除定义。一、.def 文件的基本语法规则一个.def文件按行解析规则非常简单空行被跳过不产生任何语义以//开头的行是注释同样被忽略其余每一行必然是以下三种之一指令directive行内第一个词是关键字行内其余部分是它的参数类型声明type declaration如native class ...、managed struct ...等详见 classes.md属性attribute如[nogc]、[Handle:...]作用于紧随其后的下一条声明。值得注意的细节参数可以用双引号包裹解析时引号会被剥离。例如ident engine与ident engine等价关键字不必位于行首#include foo.h也能工作因为解析器只匹配它找到的第一个单词段。这让 def 文件可以兼容 C 语法高亮——写#include时既满足了 C 高亮器又被 InteropGen 识别为include指令。这一解析行为在源码中有直接对应GlobalParser.cs 中维护了一张Directives字典把关键字映射到处理回调ParseLine则依次尝试匹配native|managed类型声明正则、属性正则最后才落到base.ParseLine处理通用指令。二、顶层指令Top-level directives下表完整列出了 def 文件可用的顶层指令指令示例含义identident engine本绑定集的名称。会成为原生初始化导出符号igen_engine并用于命名 handle 类型。nativedllnativedll engine2.dll托管端启动时加载的原生 DLL扩展名会被剥离按平台解析实际文件名。cscs ../Sandbox.Engine/Interop.Engine.cs托管输出写入位置路径相对 def 文件所在目录。cppcpp ../../src/engine2/interop.engine.cpp原生源码输出位置。hpphpp ../../src/engine2/interop.engine.h原生头文件输出位置。每个类还会在旁边生成独立子头文件interop.engine.class.h。namespacenamespace Managed.SandboxEngine生成NativeInterop/Exports类所属的命名空间——托管侧是 C# 命名空间原生侧是 C 命名空间。exceptionsexceptions Sandbox.Interop.BindingException导出托管函数抛异常时调用的托管方法签名为(string className, string functionName, Exception e)。pchpch cbase.h生成 .cpp 顶部#include的预编译头。includeinclude engine/*包含一个头文件、def 文件或文件夹——详见下一节。inheritinherit engine.def本绑定集构建在另一个绑定集之上——详见后文。skipallskipall tools.def跳过另一个 def 已覆盖的全部内容——详见后文。delegatedelegate DebugDrawDelegate_t;声明原生委托类型名使其可用作参数类型以IntPtr传递原生侧用FunctionPointerToDelegateT转换。以仓库中的真实文件 engine.def 为例可以看到全部核心指令的典型组合ident engine nativedll engine2.dll exceptions Sandbox.Interop.BindingException namespace Managed.SandboxEngine cpp ../../src/engine2/interop.engine.cpp hpp ../../src/engine2/interop.engine.h cs ../Sandbox.Engine/Interop.Engine.cs include dbg.h include color.h include engine/* include tier3 include common/* include resources注意其中ident、nativedll、exceptions、namespace、cs/cpp/hpp五类指令与文档描述一一对应include则混合使用了头文件与文件夹两种形式。结合 Program.cs 可以看到这些指令的最终去向cs决定ManagedWriter的输出路径hpp/cpp决定NativeHeaderWriter与NativeWriter的输出路径ident生成的igen_engine则是原生侧初始化导出符号。另外从源码看GlobalParser.cs 中的NativeDll处理还有一个细节nativedll的参数会剥离扩展名并统一为/分隔的正向路径也就是说nativedll engine2.dll实际记录为engine2跨平台解析时再补上对应平台的扩展名。三、include 指令的三种行为include根据参数的不同做三件完全不同的事1. 参数以.h结尾 → 头文件生成的原生头文件中会发出#include ...。惯例写法是#include vphysics2/iphysicsbody.h与include vphysics2/iphysicsbody.h解析结果完全相同——前者让你在 def 文件里写 C 风格代码时保持语法高亮正确。2. 参数以.def结尾 → 内联解析该文件会被原地解析如同其内容直接粘贴在当前位置。路径相对于包含它的文件包括文件解析。3. 其他参数 → 当作文件夹目录下每一个*.def都按字母顺序包含进来参数带尾随/*如include common/*时递归进入子文件夹。哈希联动被包含的 def 文本会计入本绑定集的定义哈希。这意味着任何被包含文件的改动都会正确使二进制配对失效——这是 sbox 防止原生/托管两侧二进制不同步的关键机制之一。四、inherit 与 skipall绑定集之间的复用与排除当多个 def 覆盖同一段原生代码时需要处理重复定义问题。仓库中tools.def构建在engine.def之上正是文档所述模式的实例见 tools.defident tools nativedll toolframework2.dll inherit engine.def include tier3 include common/* // 与 engine.def 包含的文件夹相同 include resources include tools/*inherit的语义加载另一个 def 并记住它声明过什么。这里被继承 def 声明的类型仍然会被解析两边 include 有意重叠这样才能把那些类型作为参数和返回类型引用但不会被重新发射——它们的包装器已经存在于被继承 def 的 assembly 中并且会被排除在本 def 的导出表和结构体尺寸检查之外。skipall的语义当 def 继承链变得很深时使用更强力的形式。例如tools.hammer.def同时继承engine.def、tools.def、tools.assetsystem.def时inherit tools.def skipall tools.defskipall的效果是出现在被命名 def 中的一切——类原生和托管、结构体、以及它的.hinclude——在本 def 发射时全部跳过。inherit与skipall在源码中共享同一个加载路径GlobalParser.cs 的LoadInto通过InteropPipeline.Build递归构建被引用 def然后分别加入IncludedDefinitions或SkipAll列表inherit只保留可引用skipall则进一步影响SkipPolicy的发射决策。从仓库的 manifest.def 可以看到这种层级结构Definitions/tools.def Definitions/tools.assetsystem.def Definitions/tools.hammer.def Definitions/tools.modeldoc.def Definitions/tools.animgraph.def Definitions/engine.deftools.*系列 def 都通过inherit站在engine.def的肩膀上共享同一套基础绑定同时各自只发射自己独有的部分。五、manifest.def绑定集构建清单engine/manifest.def即 manifest.def本质上只是一份待构建 def 的列表每行一个Definitions/tools.def Definitions/engine.def ...不以.def结尾的行会被忽略列表中的每个 def 会被并行处理。这与 Program.cs 中的ProcessManifest实现完全对应读取 manifest 后用EndsWith(.def)过滤行、拼上 manifest 所在目录作为路径然后为每个 defTask.Run一个ProcessDefinitionFile全部完成后汇总成功状态。构建系统Tools/SboxBuild在仓库根目录调用Facepunch.InteropGen.Program.ProcessManifest( engine )即驱动整个生成流程的入口。六、输出与构建流程中的关键约束把 def 与生成器联系起来有几个工程上必须理解的事实生成产物不入库cs/cpp/hpp指向的输出文件由构建时重新生成仓库.gitignore排除了Interop.*.cs/interop.*内容未变化的文件不会被重写两侧必须成对重建原生导出表casts、函数、变量 get/set的槽位顺序在 C 与 C# 之间按索引匹配统一由Writer/NativeExportTable.cs驱动是槽位顺序的唯一权威来源哈希防错运行时交换导出表时会校验 def 哈希陈旧的二进制会快速失败而不是运行到一半才崩改名会影响导出符号mangled 名按遇到顺序用数字后缀去重碰撞因此在 def 中重排类或成员可能重命名导出符号——两侧同时重新生成即可这正是输出必须成对再生的原因。引用路径提示需要深入了解声明语法时请继续阅读同目录的 classes.md类、结构体、枚举、函数、变量与属性声明和 types.md参数类型、编组与out/ref/CastTo[...]等标志生成器的整体流程与项目布局可参见 InteropGen 文档索引。赞分享【免费下载链接】sbox-publicsbox is a modern game engine, built on Valves Source 2 and the latest .NET technology, it provides a modern intuitive editor for creating games项目地址https://gitcode.com/gh_mirrors/sbo/sbox-public点击查看免费下载相关推荐sbox-public InteropGen 深度解析.def 驱动的 C↔C 双向绑定代码生成器sbox public InteropGen 深度解析.def 驱动的 C↔C 双向绑定代码生成器 InteropGen 是 sbox 引擎sboxOptiScaler描述符堆描述符分配与绑定的优化策略OptiScaler描述符堆描述符分配与绑定的优化策略 还在为图形渲染性能优化而苦恼OptiScaler的描述符堆管理策略为你提供了革命性的解决方案本文将图形学游戏开发Formula.js数学与三角函数实战提升数据处理效率的终极指南 Formula.js数学与三角函数实战提升数据处理效率的终极指南 想要在JavaScript中轻松实现Excel级别的数学计算吗Formula.js正数据分析上一篇如何用Midscene.js在3分钟内实现零代码视觉自动化测试终极跨平台解决方案下一篇接入联邦宇宙NodeBB ActivityPub联邦与Mastodon互通完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考