C语言[译]Godot 引擎 GDNative 架构初探

C语言 1

GDNative的架构从最早叫“DLScript”的时候到近来截止已经发生了很大的变动。随着Godot
3.0版本接近尾声宣告以及API越来越稳定,是时候对GDNative近年来的模样作一个概述了。

GDNATIVELIBRARY

GDNativeLibrary是一种资源类型。它是对每种平台所需的莫过于二进制文件的一种浮泛:包含部分属性、“入口”库加载路径清单及“入口”库所依赖库的清单。

这么些清单是一套功效特色标记的简练映射模式 –
一般是一个文件路径;假诺有依靠关系的话,就是一组路径。

特色标记

Godot有一套特性标记系统。特性标记表示拥有相应的特定的性能或效益,例如Windows,
X11, 32, 64,
mobile等等。在导出游戏时,你也足以自行定义标记,从而可能改变游戏的运转情势。

更多关于特性标记的信息,可以去http://docs.godotengine.org/en/latest/learning/workflow/export/feature\_tags.html查看。

GDNativeLibrary资源中的列表由键值对格局整合,键中按照需要可以分包五个特征标记,以英文句点“.”分隔。

譬如说一个支撑64位Linux机器的库,它的键名即“X11.64”,假设对应的是Windows的机械,则键名为“Windows.64”。

Godot编辑器提供了GUI来更人性化的展开这种资源的定义和编排。

C语言 2

它会从上而下的对所有入口举办检测,并跳过那多少个不设有的特性标记。在拥有可用的标志中,第一个会被用作入口,所以排序很首要。

SINGLETON 库

GDNativeLibrary中有一个属性是用以定义其是否辅助单例格局利用的。单例库会在Godot启动期间尽量早地载入,且会调用库中的gdnative_singleton函数。这种库常用于需要提供与Godot紧密结合的机能。

GDNATIVE

GDNative对象表示所载入的库,至于实际要加载哪个库就要从GDNativeLibrary资源文件中万分了,Godot环境下的C++代码可以去调用该库中的函数。由于这种方法去调用函数太过灵敏、底层且不安全,所以是不提议从GDScript这一个脚本语言中去调的。

倘使真想从脚本语言环境一向调用相应成效,可以用GDNative.call_native方法来满意急需。对于那种函数指针调用的底部细节,抽象出了一种所谓的“调用类型”来进展描述。目前仅有一种预定义调用项目:standard_varcall

  • 渴求被调用的函数签名为
    godot_variant function_name(godot_array *)。单例库可以按需注册新的调用类型。

GDNATIVE/GODOT API

固然某个库想调用Godot的局部意义,它就需要去调用Godot的代码。而各个C++编译器之间的移植性分外有问题,所以我们采用用C语言API的款型来封装对C++的调用。这开启了多种语言访问API的可能性,但也带动了有些冗余性。

API 结构

一个库为了访问那个用C封装的函数,它首先要清楚那多少个函数的岗位。最直接的想法是留空,然后让操作系统的库加载机制来处理。

欠好的是,这种艺术不可以在所有平台正常运行(此处Windows可能要窘迫的咳两声),所以为了保险在享有平台安装GDNative库用平等的代码和步子,我们决定选择另一种途径:在加载函数时,以函数指针结构(struct)的款式传递。

该协会存在于Godot中,并带有版本音信、以后的API改动字段及增添API列表。

struct godot_gdnative_api_struct {
    unsigned int type;
    godot_gdnative_api_version version;
    const godot_gdnative_api_struct *next;
};

struct godot_gdnative_core_api_struct {
    unsigned int type;
    godot_gdnative_api_version version;
    const godot_gdnative_api_struct *next;
    unsigned int num_extensions;
const godot_gdnative_api_struct **extensions;
    // ...
};

库可以从这种struct中走访所需的函数,也就象征不再是编制
godot_some_function();这种模式了,而是api->godot_some_function();

多少人欣赏简单的通过函数名而不是struct来拜会函数,所以在有需要时,Godot的构建系统会转变一个静态库,来包裹所有的同名函数指针为静态函数。

扩展

GDNative 扩张是一种给库提供GDNative/Godot API
之外功效的不二法门。它们可以不同方法接纳,下边会列出二种当前支撑的样式的壮大。

扩大平常带有C语言API,可能还伴随着有自定义数据类型。Godot里一般有用于包裹这些和此外效用密切结合的C函数的C++类/方法。

各种扩大都有它自己的子API结构,其中蕴藏了版本消息及前景API修改音讯的字段。

ARVR

运用GDNative来落实一种VR驱动的有着API能够参见文档: file。

这套API的起源是 godot_arvr_register_interface
函数,它需要从一个单例库举办调用。这个要被Godot调用的函数则集体成一个结构以参数的形式传递过去。

目前有 null-driver 的实现、 OpenVR 的实现 和 WIP OpenHMD 的实现。

NATIVESCRIPT

GDNative的最初开爆发涯里,它仅被计划用于脚本化编程,后来被发掘出更多利(Dolly)索和卓有功效的地点,脚本化编程能力现在单独是内部一个恢弘。

NativeScript 实现了一套“脚本语言” –
在Godot中得以那样叫,但事实上是用GDNative库而不是像GDScript这样的文件和文书的款型来保存有关逻辑。

NativeScript会调用库中的一个函数 nativescript_init
告知Godot哪些类和艺术是可用的。在要用到这些类和格局的时候,NativeScript就能很简单的去调用这一个库来贯彻相应功用。

因为 NativeScript
仅对库开展操作,它并不关心那么些库是用哪些语言构建的,假诺开发者要用自己喜爱的编程语言举行库的付出,就使得
NativeScript 成为 Godot
里的一种一级选项,即便在这一个基础上还要付出良多开足马力。

这想要更灵敏且更像脚本的感到的话,就应该考虑用一下 PluginScript 了。

PLUGINSCRIPT

PluginScript也是一个恢宏,它给Godot参预了封装脚本语言实现的风味。对Godot而言,它是一种运行优良且完全集成的脚本语言,但装有逻辑都是在一个库中贯彻的。

NativeScript
把库都当作脚本用,而PluginScript是用库来定义脚本。也就是一旦在你的Godot项目中添加一些文件,就足以添加一种新的脚本语言援助。

最近停止,这种“野生”的重要利用还唯有一个 godot-python项目。

与ARVR扩充类似,PluginScript的API也是非凡小巧,仅有一个内需调用的函数
godot_pluginscript_register_language。该函数接受一个struct作为参数,struct里富含函数指针及脚本语言的此外信息。

Godot编辑器重启后,就能奏效了。

计划

俺们正在计划成立更多的增添,如可插拔式音录像解码器。

对此GDNative当前的架构,我们早已相当满足了,下一步关键是宏观文档和改善语言绑定。